qunitjs / qunit / 9322063078

62%

main: 90%

push

github

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, thi... (continued)

5 of 13 new or added lines in 2 files covered. (38.46%)

1278 of 2056 relevant lines covered (62.16%)

1914.34 hits per line