pushFailure giving wrong error? #440

rzurad opened this Issue Apr 12, 2013 · 3 comments


None yet
4 participants

rzurad commented Apr 12, 2013


I'm setting up a project that uses QUnit 1.11.0 to test modules loaded in via RequireJS and is run via TestSwarm. During my debugging of getting all the components to play nice with each other, I kept seeing error messages pop up saying "pushFailure() assertion outside test context", which didn't make any sense to me since I was only testing incredibly simple assertions like ok(true, 'true'); without QUnit modules

Debugging into it, I found that every time I was getting these errors, it didn't actually seem to be the correct error. Since I'm using RequireJS to load test modules, I need to defer the running of QUnit, so I had to set QUnit.config.autostart = false; and call start manually after all the modules were loaded.

What was actually happening was the start function did its semaphore check, and found that the condition config.semaphore < 0 was true (for various reasons while getting things in order: because I had incorrectly set QUnit.autostart = false; instead of QUnit.config.autostart = false; or by having accidental double callback execution, etc) so it calls pushFailure with "Called start() while already started...", but the first thing pushFailure does is see that there is not a config.current and throw the new error telling me I have an assertion in the wrong place.

Can someone enlighten me as to why this is? It seems to me to be a bug because after I get my start calls in order, everything works, so I'm not sure why in these conditions it thinks that the assertion being out of context error is more important than the "I'm already running" error.

If there is a reason for this, awesome, but if there isn't, it could have saved me a bit of debugging time if the error message was actually correct.

Hi, I was getting similar errors using PhantomJS.

I use this hack to deal with the issue with my RequireJS-based tests. I import my qunit.mod.js as a RequireJS shim in my tests, but using a regular script tag would work as long as you set the value of QUnit before importing qunit.mod.js.

<script type="text/javascript" src="require-config.js"></script>
<script type="text/javascript" src="../../lib/requirejs/require.js" data-main="test-main"></script>
// disable autoload on hacked QUnit
QUnit = { autoload: false };
require(["jquery", "qunit", "test-main", "path/to/test", "es5shim", "domReady"], function ($, QUnit, testMain, testModule) {

And my qunit.mod.js, based on qunit.js 1.11.0, with links to the original code lines:

L2152 - Pass any pre-existing QUnit object to the IIFE.

}( (function() {return this;}.call()), /*grimbo: added test for initial config*/ this['QUnit'] ) );

L11 - Add a parameter for pre-existing QUnit. Call it initialQUnit.

(function( window, /*grimbo: added parameter*/ initialQUnit) {

L688 - Extend the default config with initialQUnit, to pick up any existing values.

/*grimbo: extend the initialQUnit to pick up 'bootstrap' properties. */
config = extend(initialQUnit || {}, {

L1184 - Use the new autoload config option.

/*grimbo: added autoload check. autoload must be explicitly false to prevent. */
if ( false !== config.autoload ) {
    var _load = function () { console.log("QUnit.onload"); QUnit.load(); };
    addEvent( window, "load", _load );
    //addEvent( window, "load", QUnit.load );

I couldn't get any other combination of autostart/autoload to work with my RequireJS modules in both the browser and PhantomJS environments.

Hope some of this might help if you're still having trouble.


JamesMGreene commented May 9, 2013

IIRC, advice per @jrburke is to just include script tags for QUnit and configuration tweaks prior to your main require/define bootstrapping.

However, as a huge proponent of RequireJS myself, I make use of the shim configuration's init callback:

    shim: {
        'qunit': {
            init: function() {
                this.QUnit.config.autostart = false;
                return this.QUnit;

jzaefferer commented Feb 13, 2014

We could look into this again if someone provides a testpage to reproduce the problem.

jzaefferer closed this Feb 13, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment