I’m running a set of QUnit tests that use module level setup and teardown methods. I’ve noticed that using start() and stop() inside my tests appears to disrupt when these get called, which causes problems as certain items made available in my setup are not available to some tests that run.
Edit: I’ve noticed that this happens exclusively when I load my test scripts programmatically (I’m using a script loader: LABjs). I have modified the subject and content of this question accordingly. I am loading tests like this:
$LAB.script('/static/tests.js')
Still not sure why this happens.
Here’s a sample of my test module:
module('Class Foo', {
setup: function() {
console.log('setup called');
},
teardown: function() {
console.log('teardown called');
}
});
test('Test1', function() {
stop();
console.log('test1');
ok(true);
start();
});
test('Test2', function() {
stop();
console.log('test2');
ok(true);
start();
});
test('Test3', function() {
stop();
console.log('test3');
ok(true);
start();
});
This yields the console output (note that setup is called twice, then not again):
setup called
test1
teardown called
(2)setup called
test3
teardown called
test2
teardown called
Remove the start/stop, or modifying my test files to not be loaded programatically (i.e.: using traditional tags):
test('Test3', function() {
console.log('test3');
ok(true);
});
Yields a more expected order of execution:
setup called
test1
teardown called
setup called
test2
teardown called
setup called
test3
teardown called
Am I misunderstanding something about how this should be functioning?
It appears that QUnit likes your test scripts to be loaded when it kicks itself off. This action is configurable, so I found the following setup worked to defer QUnit starting until all test scripts were available:
I’m still not sure why this happens so would be interested to see any answers in that regard (or I’ll update this when I figure it out!) but this solution gets me by for now.