-
Notifications
You must be signed in to change notification settings - Fork 781
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Core: Remove deprecated
QUnit.load()
* Move scheduleBegin() code into QUnit.start(). * Remove internal config.pageLoaded, unused. * Remove redundant `config.blocking` assignment, already set by begin(). == Reasoning for DOM-ready delay in QUnit.start == After the above changes, /test/startError.html failed when run via grunt-contrib-qunit (e.g. CI) due to a Chrome timeout with no test results. It passed in a browser. I realised that this is because the bridge is injected after QUnit.start() and our tiny test were already finishesd. I believe this would affect even simple cases where someone sets autostart=false and correctly calls QUnit.start(). This worked before because legacy QUnit.load/QUnit.autostart was implicitly delaying the begin() call even if you don't use autostart or call load+start both. The reason is the `config.pageLoaded`. If the user disables autostart, it is common for them to use async code loading (e.g. AMD) and thus start manually after DOM-ready. But, it is entirely valid for them to be ready before DOM-ready in some cases. In that case, our legacy logic was still kicking in by re-enabling autostart and then waiting for the original html.js event handler for window.onload to call QUnit.start() before we "really" begin. I don't remember if that was a lazy way to resolve conflicts between the two, or a deliberate feature. We deprecated the conflict handling part of this in QUnit 2 and this patch removes that. But, it seems this was also serving as a feature to always ensure we wait for DOM-ready no matter what, which is actually very useful to making sure that integrations and reporter plugins have a chance to listen for "runStart". Solution: If you call QUnit.start(), and there is a document, and we've not reached `document.readyStart=complete` (i.e. you called it manually, most likely with autostart=false), then we will now still explicitly wait for window.onload before calling begin(). For all intents and purposes, this delay is now invisible and internal to QUnit. We do consider QUnit to have "started" during this delay. We were already using setTimeout previously between `start` and `begin` and this is effectively and extension of that. Ref #1084
- Loading branch information
Showing
5 changed files
with
61 additions
and
102 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,34 +1,42 @@ | ||
/* eslint-env browser */ | ||
|
||
QUnit.config.autostart = false; | ||
|
||
// Real | ||
QUnit.start(); | ||
|
||
// Bad 1 | ||
QUnit.config.autostart = true; | ||
try { | ||
QUnit.config.autostart = true; | ||
QUnit.start(); | ||
} catch (thrownError) { | ||
window.autostartStartError = thrownError; | ||
} | ||
|
||
// Bad 2 | ||
QUnit.config.autostart = false; | ||
try { | ||
QUnit.start(); | ||
} catch (thrownError) { | ||
window.tooManyStartsError = thrownError; | ||
} | ||
|
||
QUnit.module('global start unrecoverable errors'); | ||
QUnit.module('startError'); | ||
|
||
QUnit.test('start() throws when QUnit.config.autostart === true', function (assert) { | ||
assert.equal(window.autostartStartError.message, | ||
'Called start() outside of a test context when QUnit.config.autostart was true'); | ||
QUnit.test('start() with autostart enabled [Bad 1]', function (assert) { | ||
assert.propContains(window.autostartStartError, | ||
{ message: 'QUnit.start() called too many times. Did you call QUnit.start() in browser context when autostart is also enabled? https://qunitjs.com/api/QUnit/start/' }); | ||
}); | ||
|
||
QUnit.test('Throws after calling start() too many times outside of a test context', function (assert) { | ||
assert.equal(window.tooManyStartsError.message, | ||
'Called start() outside of a test context too many times'); | ||
QUnit.test('start() again [Bad 2]', function (assert) { | ||
assert.propContains(window.tooManyStartsError, | ||
{ message: 'QUnit.start() called too many times.' }); | ||
}); | ||
|
||
QUnit.test('QUnit.start cannot be called inside a test context.', function (assert) { | ||
QUnit.test('start() inside a test', function (assert) { | ||
assert.throws(function () { | ||
// eslint-disable-next-line qunit/no-qunit-start-in-tests | ||
QUnit.start(); | ||
}, | ||
/QUnit\.start cannot be called inside a test context\./); | ||
new Error('QUnit.start cannot be called inside a test.')); | ||
}); |
@izelnakri FYI: This is now easier to reset for you at https://github.com/izelnakri/qunitx/blob/c4fc5c92697403abb73078ca408139184d19a367/build.js#L13, as the state is now encapsulated in config rather than a local variable.
I think you won't have to augment qunit.js after this, as you could now define that
reset()
function on its own. Let me know if that's not the case!