You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* 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
thrownewError('QUnit.start cannot be called inside a test context.');
72
-
}
73
-
74
-
constglobalStartAlreadyCalled=globalStartCalled;
75
-
globalStartCalled=true;
76
-
77
-
if(runStarted){
78
-
thrownewError('Called start() while test already started running');
79
-
}
80
-
if(globalStartAlreadyCalled||count>1){
81
-
thrownewError('Called start() outside of a test context too many times');
68
+
thrownewError('QUnit.start cannot be called inside a test.');
82
69
}
83
-
if(config.autostart){
84
-
thrownewError('Called start() outside of a test context when '+
85
-
'QUnit.config.autostart was true');
70
+
if(config._runStarted){
71
+
if(document&&config.autostart){
72
+
thrownewError('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/');
73
+
}
74
+
thrownewError('QUnit.start() called too many times.');
86
75
}
87
76
88
-
// Until we remove QUnit.load() in QUnit 3, we keep `pageLoaded`.
89
-
// It no longer serves any purpose other than to support old test runners
90
-
// that still call only QUnit.load(), or that call both it and QUnit.start().
91
-
if(!config.pageLoaded){
92
-
// If the test runner used `autostart = false` and is calling QUnit.start()
93
-
// to tell is their resources are ready, but the browser isn't ready yet,
94
-
// then enable autostart now, and we'll let the tests really start after
95
-
// the browser's "load" event handler calls autostart().
96
-
config.autostart=true;
97
-
98
-
// If we're in Node or another non-browser environment, we start now as there
99
-
// won't be any "load" event. We return early either way since autostart
100
-
// is responsible for calling scheduleBegin (avoid "beginning" twice).
101
-
if(!document){
102
-
QUnit.autostart();
103
-
}
77
+
config._runStarted=true;
104
78
105
-
return;
79
+
// Add a slight delay to allow definition of more modules and tests.
QUnit.test('start() throws when QUnit.config.autostart === true',function(assert){
19
-
assert.equal(window.autostartStartError.message,
20
-
'Called start() outside of a test context when QUnit.config.autostart was true');
26
+
QUnit.test('start() with autostart enabled [Bad 1]',function(assert){
27
+
assert.propContains(window.autostartStartError,
28
+
{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/'});
21
29
});
22
30
23
-
QUnit.test('Throws after calling start() too many times outside of a test context',function(assert){
24
-
assert.equal(window.tooManyStartsError.message,
25
-
'Called start() outside of a test context too many times');
31
+
QUnit.test('start() again [Bad 2]',function(assert){
32
+
assert.propContains(window.tooManyStartsError,
33
+
{message: 'QUnit.start() called too many times.'});
26
34
});
27
35
28
-
QUnit.test('QUnit.start cannot be called inside a test context.',function(assert){
36
+
QUnit.test('start() inside a test',function(assert){
0 commit comments