For QUnit v2.x, I think we should change QUnit.start/QUnit.stop to be straight-forward block/unblock without a semaphore (or rename them altogether to avoid confusion with the v1.x behavior) but they still need access to the semaphore for backward compatibility right now.

I'm missing also the deprecation messages on asyncTest and QUnit.config.semaphore.

I also vote for deprecating QUnit.stop() and keeping QUnit.start() to only handle the global config.autostart. Tests' semaphores should be handled only by assert.async, that shouldn't care about global semaphore.

For 2.0.0, I would like to make all tests assert.async() by default, making them to fill expected assertions or calling assert.done, as previously mentioned by @jzaefferer.

To make tests async by default, we would need to either:

• provide the initially created done function somewhere, e.g. as an additional argument passed to the function callback

QUnit.test( "x", function( assert, done ) {
  /* ... */
  done();
});

• or as a contextual property (e.g. this.done();), which may have conflicts when migrating from v1.x to v2.x.

also as assert.done();, no?

anyway, let's bring this 2.0.0 discussion to another issue so here we can focus on the changes on this PR.

also as assert.done();, no?

assert.done is not planned.

I'm missing also the deprecation messages on asyncTest and QUnit.config.semaphore.

Added deprecation warnings for QUnit.start, QUnit.stop, QUnit.asyncTest, and QUnit.config.semaphore.

For 2.0.0, I would like to make all tests assert.async() by default, making them to fill expected assertions or calling assert.done, as previously mentioned by @jzaefferer.

That's not really what I suggested (I hope). With the two approaches we're going for now, I don't think we really need something else.

The third approach would be to make assert.expect() trigger an async test, then running the specified of assertions ending the test. That wouldn't work for expect(0), which we currently support. There's probably more reasons why this isn't great, at least in the context of our existing APIs.

Please ignore style issues with lines that are too long until #654 is addressed, which will help fix these. That kind of issue is just distracting from the important parts here.

Other than that, \o/ \o/ \o/

This is great.

Thanks, @gibson042!

@jzaefferer @leobalter @Krinkle: Did you guys want to review this PR further? I'm not sure I have anyone's stamp of approval yet.

LGTM, so I reported only few style issues I saw

@leobalter: All fixed, and a few more.

So @leobalter and @gibson042 have approved now.

@jzaefferer @Krinkle @scottgonzalez, did any of you want to review this further before it gets merged?

Forewarning: The Promise PR (#634) will be ready for rebasing for further review and/or merging immediately after this one is merged, so you should also go review that one (which contains this PR as well) before I have to pester you. 😜

Overall looking very promising. No game-breaker, just some details that we need to iron out. No need to discuss setTimeout support here, I'll open a separate ticket for that.

The new commit implemented all of the error scenario rules for QUnit.start/QUnit.stop per my comment #653 (comment), which I am still currently assuming are what @jzaefferer was implying in his comment #653 (comment).

LGTM