Hm, are you using the latest version of QUnit (v1.11.0)? I've only been able to reproduce the issue in #44 using the latest version, since it works fine with the bundled version of QUnit in Yeti right now (v1.10.0), though the part of inject.js that you mention isn't running at all, like you said. The reason it doesn't have an error in the older version of QUnit is that they recently added an assertion when Qunit.start() is called twice, but the tests still correctly run.

It looks like the underlying issue is the changes to QUnit's way of handling asynchronous tests, as seen in their changelog. This issue (qunitjs/qunit#314), and the start/init issues related to that one are the main cause of the problems in the newer version. I do agree with the decision that the QUnit team chose to handle that issue, though.

From what I've tried out so far, there's other ways of solving the problem, but most of it involves messing with QUnit internals, which isn't too great. I'd support merging this in for now, and opening up an issue with the QUnit team to discuss a better way of handling QUnit.init()/Qunit.start() for use cases such as the one in Yeti.

Yes, I was trying the latest one.

But any idea why YUI's domready triggers after window.onload? It could be perfect place for disabling autostart.

I believe it's because YUI.use() waits for all of the modules to loaded and attached before executing the callback. Loading those modules, it seems, takes longer than the load event, or even domready.

Another possible solution would be to set bootstrap to false in the Loader, and do the QUnit auto-start disabling there. Then, we would just need to manually make sure Y.InjectedDriver was ready before setting it all up.

@reid probably has more knowledge about me about that, and I'd also definitely love to hear his input on this.

@clarle All of the modules Yeti needs should be already be on the page. It wouldn't hurt to set bootstrap to false, which may prevent the delay. Not certain.

For reference: http://yuilibrary.com/yui/docs/api/classes/config.html#property_bootstrap

We should have Y.InjectedDriver ready to go since scripts/fetch_deps.js downloaded all YUI dependencies in advance.

yeti is broken for QUnit, please release this fix ASAP.

@jskungfu Thanks for chiming in, I'd like to release this week. Does this fix work for you? /cc @jayarjo

I am getting this error and seems like somewhat related to global failure of QUnit.

I thought I'd bring that bunyip fork of mine to a sane state (Yeti + Sauce Labs or BrowserStack, including local casual testing or in Travis CI) after all, but the problem described in the original pull request still persists. Do you plan to resolve it somehow?

Btw, may I ask you for a comment? From my everyday perspective something like bunyip might be useful, but it is interesting what do you guys think about it, since you obviously got a wider view on the whole thing? Maybe there's a simpler way and it doesn't worth it?