Matt Kruse wrote:
Does anyone actively use JSUnit < http://www.edwardh.com/jsunit/ > for
unit testing their javascript code?
For logical functions, I imagine it could be very useful.
However, I'm wondering how well it would work for other things which
are browser-dependent, like DHTML. Any personal success or horror
stories?
Kupu uses ecmaunit rather than jsunit, but since they are both just xUnit
implementations the same principles apply. The degree to which unit tests
are actually implemented for Kupu has varied over time, current the trunk
has 71 tests. In particular one of the developers has recently been adding
tests for some of the harder areas to test: We have some classes which
manipulate selections in an editable iframe, so the tests have to set up a
suitable iframe, add content, select it, do the test, then clean up the
iframe. Here's a test I wrote using his _setSelection support method:
this.testSetTex tStyle = function() {
var data = '<p>line 1</p><div class="Caption" >line 2</div><div
class="Caption" >line 3</div>';
// select ............... ............... .......|e 2</div><div
class="Caption" >line|...
var expected = '<p>line 1</p><h2>line 2</h2><h2>line 3</h2>';
this.body.inner HTML = data;
this._setSelect ion(10, null, 18, null, 'e 2line');
this.ui.setText Style('h2');
this.assertEqua ls(this.cleanHt ml(this.body.in nerHTML), expected);
}
_setSelection here is asked to select the 10th to 18th characters and
verify it has selected 'e 2line', the string being provided to act as a
double check on the counting (and when first written the selected text
didn't match on the different browsers). Then the actual test: call the
ui.setTextStyle method to set the currently selected region to a level 2
heading, then verify that the resulting HTML matches what we expect (with
appropriate cleanup to remove browser inconsistencies ):
this.cleanHtml = function(s) {
s = s.toLowerCase() .replace(/[\r\n]/g, "");
s = s.replace(/\>[ ]+\</g, "><");
return s;
}
Since almost all the methods which are tested are supposed to be cross
browser (or in Kupu's case cross-browser so long as your browser is in the
list of supported browsers), browser dependency is handled simply by making
sure that all tests pass on both Mozilla and IE. I usually run with a tab
or window open on the unit tests for each browser and concentrate on
developing on Mozilla but every so often check the tests still run on IE.
Occasionally there are problems with one platform but not the other: the
worst one was that I recently found that every time the tests ran on IE
they took 0.2 seconds longer than the previous time: the class
containing the test I showed above needs to set up more of the Kupu
environment than most of the tests and tearDown wasn't managing to tidy
everything well enough.
Feel free to look at the Kupu sources from
http://codespeak.net/svn/kupu/trunk/kupu, get ecmaunit from
http://codespeak.net/svn/kupu/trunk/ecmaunit. Run the javascript tests from
kupu/tests/run_tests.html. The test I quoted comes from test_plone.js and
that testcase subclasses SelectionTestCa se in test_kupuhelper s.js.
