Last modified: 2013-04-08 07:47:03 UTC
For bug 44299, I created a bad .js file that causes errors in Extension:E3Experiments's ResourceLoader modules. However, when I run http://localhost/wiki/index.php/Special:JavaScriptTest/qunit in non-debug mode with this bad .js in place: * There's no report from qunit that any modules are in "error" state. * The E3Experiments qunit test is silently omitted from the list of tested modules and the dropdown, but there's no warning. * If I force the E3Experiments test to run with http://localhost/wiki/index.php/Special:JavaScriptTest/qunit?module=ext.E3Experiments.standalone , it reports "0 tests of 0 passed, 0 failed", but otherwise looks OK. The E3Experiments qunit test is very incomplete, it can run standalone and barely tests any functionality. But mw.loader.getState('ext.Experiments.tests') is "error" also, so I would expect some notification from qunit that there was a problem.
Is that js file a lib file or a test file? What do you get in the console? QUnit can/should only execute tests it is given. Test it isn't given it can't load, naturally. If a file contains a SyntaxError the module it came with will fail at run time, so anything else that module provided is not executable, this is how javascript works (nothing we can do about it). Special:JavaScriptTest/qunit?module=ext.E3Experiments.standalone showing 0/0 is misleading. the module parameter is a filter. The module you're referring to isn't loaded due to the invalid syntax, so the filter doesn't match any modules. Special:JavaScriptTest/qunit?module=blablabla yields the same result. I don't think QUnit is the place to assert syntax correctness. That's what JSHint is for, which should run before one even considers running QUnit tests. Also, in a non-automated environment the console will inform about the syntax error.
attachment 11696 [details] (http://bug-attachment.wikimedia.org/attachment.cgi?id=11696, key code below) is just some JavaScript, you can add it to any module. It passes JSHint without warnings Thanks for the explanation. I thought QUnit ran the test modules you add to $testModules['qunit'] in response to the ResourceLoaderTestModules hook. If you give it a RL module that didn't load, surely *someone* should complain? function failsInIE() { var myArr = [ 42, 666 ]; if ( myArr.indexOf( 666 ) === -1 ) { return false; } } function failsEverywhere() { return window.badTypo(); } // Could call it always, could call it sometimes... failsInIE(); failsEverywhere();
I believe Krinkle's Change-Id: Ib6e2b8d1be3e38fd9f1b948407c62da550fce0b4 mentioned in bug 44299 fixed this, yay! To verify, I added bad code to an extension's module that is referenced by its qunit tests ( var x = window.badTypo(); near the end of extensions/GuidedTour/modules/ext.guidedTour.lib.js ) and "mediawiki.tests.qunit.testrunner Loader status" fails and lists the module and others depending on it as "Modules in error state". Note that if you have the cookie resourceLoaderDebug set to true (or if you check Enable ResourceLoaderDebug on the Special:JavaScriptTest/qunit page), then the state of the broken RL module will be "ready" in both qunit tests and regular pages that load it.
