-
Notifications
You must be signed in to change notification settings - Fork 781
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate QUnit.load #1084
Comments
I agree with this in general, because I get tripped up on |
We need to discuss this, but I believe calling start() on every run is not a bad idea compared to the magic of autostarting in a browser. The responsibility to catch the document.ready or the window.load events are not for a test runner. |
FWIW, the reporter is actually what currently handles the autostart on load behavior. We could just update this to call |
I thought about this, but this might break suites using config.autostart and user defined start |
I guess we have this fixed. Checking. |
I've begun working on this. I'd like to deprecate it so that we can remove it in 3.0. However, the interplay between |
Fixes qunitjs#1084 Modularize and export load implementation The load impl remains as-is The QUnit.load entry point issues deprecation warning
I took a pass at untangling the start/load logic: master...smcclure15:untangle-load-logic Most of that endeavor was for my own understanding, getting my head around what the valid sequences were among these APIs. I hope by sharing that it can benefit others as well. It's a dense change in the end, but I tried to get each of the 3 commits fairly clean: 1, it flattens some of the if/else logic in start. Fewer nested checks. I believe everything is still intact - all tests pass and I bashed it quite it bit. I do worry about edge cases in this, and wouldn't PR it until I hit it really hard. I think what this cleaner (I hope!) logic is telling me is that our recommendations for what to do when This is all independent of #1502, which is just a matter of issuing a warning and making the reporter use a non-warning version. Once the Open to your thoughts and discussion |
@smcclure15 Thanks for that analysis. I agree with the objective and conclusion, one either uses the default My worry is that abiding by that may be non-trivial for end-users to figure out within their current systems. I'd like us to cover a good chunk of what It's been a while I looked at this, so maybe its obvious and mostly covered here already. Just wanted to clarify that goal. |
The following analysis starts with a trivial passing test: QUnit.test( "example", assert => {
assert.true( true );
} ); and adds various combinations of calls to Node environment with QUnit CLISynchronous run executionAdding QUnit.config.autostart = false;
QUnit.test( "example", assert => {
assert.true( true );
} ); Adding one (or more!) QUnit.config.autostart = false;
QUnit.load();
QUnit.load();
QUnit.load();
QUnit.test( "example", assert => {
assert.true( true );
} );
QUnit.load();
QUnit.load();
QUnit.load(); But using // QUnit.config.autostart = false;
QUnit.load();
QUnit.test( "example", assert => {
assert.true( true );
} );
Similarly, using any QUnit.test( "example", assert => {
assert.true( true );
} );
QUnit.start();
TAKEAWAY: Don't use Asynchronous run executionThis actually fails with both QUnit.config.autostart = false;
setTimeout(() => {
QUnit.test( "example", assert => {
assert.true( true );
});
QUnit.start();
}, 100)
and has a trailing exception from within the framework 100ms later:
This has no impact on deprecating Writing your own CLI with js-reportersUsers can leverage the js-reporters project and build their own CLI runner, via something like the following: const JsReporters = require("js-reporters");
const runner = JsReporters.autoRegister();
JsReporters.TapReporter.init(runner);
// load tests
require(test);
// kick off test execution
QUnit.load(); If the test file that is required is the "trivial" test case, replacing If the test that is required uses Browser environmentSynchronous run executionUsing one or more QUnit.load();
QUnit.load();
QUnit.load();
QUnit.test( "example", assert => {
assert.true( true );
});
QUnit.load();
QUnit.load();
QUnit.load(); Asynchronous run executionUnlike the Node example that failed with no tests run, the following successfully passes: QUnit.config.autostart = false;
setTimeout(() => {
QUnit.test( "example", assert => {
assert.true( true );
});
QUnit.start();
}, 100) Here, the |
This is an ancient left-over from when the async test API consisted of `QUnit.stop` and `QUnit.start` (as opposed to `assert.async()` and the built-in test promise await), where `QUnit.start` was also at the same time responsible for the initial starting of executing the test run for cases where autostart=false (aka "begin"). Part of this legacy remains at #1084. == Rollup, before > (!) Circular dependencies > src/core.js -> src/test.js -> src/core.js > src/test.js -> src/core/processing-queue.js -> src/test.js == Rollup, after > (!) Circular dependency > src/test.js -> src/core/processing-queue.js -> src/test.js
Based on qunitjs#1502 by @smcclure15. Closes qunitjs#1084. Co-authored-by: Steve <[email protected]>
Based on qunitjs#1502 by @smcclure15. Closes qunitjs#1084. Co-authored-by: Steve <[email protected]>
Based on #1502. Closes #1084. Co-authored-by: Steve <[email protected]>
* 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
Tip
Migration guide has been published at: https://api.qunitjs.com/QUnit/load/
This is not even documented, but it's used everywhere.
We need to make it an unnecessary call and then warn if it's called.
Subtasks
QUnit.load
and add examples of how to accomplish these use cases instead.The text was updated successfully, but these errors were encountered: