I believe this might be an example of this problem in the wild.
If tests are loaded asynchronously, the document is loaded before they are read, which changes the values of config.autorun and config.blocking and eventually causes the callbacks queued in Test.queue() to be run out-of-sequence.
This pull request contains a separate test HTML file with accompanying JS tests that exemplify the problem.
The exact sequence of problematic events goes like this:
And now you're thinking with portals.
add a test that exemplifies the async load problem
nice job, good test though, i had the same idea with the array for the stack exchange post but yours is more elegant.
Usually what you need to do here is to set QUnit.config.autorun = false, then call QUnit.start() once you're done loading tests. Certainly needs (better) documentation, but I don't think there's much the framework could do.
QUnit.config.autorun = false
There's an example for using QUnit.config.autostart in the API documentation now: http://api.qunitjs.com/QUnit.config/
Beyond that I would need more input to address this, until then I've got to assume the above is a valid solution.
thanks, that solved it. I'm glad that you have now a real api documentation.
@jzaefferer - How about adding QUnit.config.autostart to the file in my test? I don't think there's already a test for this functionality (is there?)
@mcantor good suggestion, thanks. Landed in 4e03a4b