start() may happen before init()

[rodneyrehm]

Using Require.js we've run into a funny issue. Apparently QUnit.init (via window.load) is triggered after reqired resource have been loaded. Since QUnit.config.autostart = false; is in play, we call QUnit.start() in the master test-file. (as suggested in this Example).

The quickest solution @jzaefferer and me found is diverting calls to start() unless QUnit is initialized. Achieve with

1. add QUnit._initialized = true; to QUnit.init();
2. prepend the following to QUnit.start():

if (!QUnit._initialized) {
    // defer execution until the thing has initialized
    setTimeout(function() {
        QUnit.start(count);
    }, 50);
    return;
}

@jzaefferer also voiced concerns this could break on headless browsers. (I have no clue what that break could be…)

[jzaefferer]

When running headless without a DOM, QUnit.init never runs. In that case the workaround would break stuff.

Should probably refactor QUnit.init() to initialize the config while QUnit loads, and move the DOM init stuff into QUnit.load, where a bunch of other DOM interaction happens anyway.

[rodneyrehm]

ok, you had me confused there. headless - in my simple mind - is a browser that doesn't paint to screen, it still has a dom, though. What you mean - again in my words - is a javascript shell (node, or whatever, something that is not a browser).

Anyway, splitting up default config and DOM init makes sense! This doesn't solve the problem though, as tests could depend on the initialized dom, no?

[jzaefferer]

If there's no UI (aka headless), results are only available via logging callbacks. Though if the DOM is available, it needs to be update before running the first test. So yeah, for that case, the order needs to get fixed.

[jzaefferer]

Discussed with Scott in IRC, probably need to do something like this: have QUnit.start() wait for QUnit.load (if there's a dom), if there's none, init immediately. Wrap the DOM access in QUnit.init() to make that also work without DOM.