I've been thinking about this in the context of doctest.js (though not actually doing anything about it), and while this would solve part of the problem sometimes you really need to let go of the interpreter, particularly when dealing with the DOM. For this reason I think generally a function-that-does-stuff is a bad way to setup a JS test. In the case of doctest.js I think it would be possible (with lots of refactoring) to actually solve this fairly transparently in the test framework, but deconstructing the functions in jsUnit doesn't seem possible.
Isn't this the same TotT from March 29, 2007? I have it printed out in my cubical and it sure looks the same. I'm not complaining, but perhaps a "TotT Classic" title would be more appropriate?
I've been thinking about this in the context of doctest.js (though not actually doing anything about it), and while this would solve part of the problem sometimes you really need to let go of the interpreter, particularly when dealing with the DOM. For this reason I think generally a function-that-does-stuff is a bad way to setup a JS test. In the case of doctest.js I think it would be possible (with lots of refactoring) to actually solve this fairly transparently in the test framework, but deconstructing the functions in jsUnit doesn't seem possible.
ReplyDeleteIsn't this the same TotT from March 29, 2007? I have it printed out in my cubical and it sure looks the same. I'm not complaining, but perhaps a "TotT Classic" title would be more appropriate?
ReplyDelete