|
|
This test was an awful, awful, mess. (And I take full responsibility.)
Changing the global user language mid-way into execution is in no way
supported by ResourceLoader and this test was going through great
lengths to fool mw.loader about what's really going on.
Basically, all we're doing is get a list of instructions on what tests
to run, get comparison values based how the PHP side proceses these
(for parity comparison), and then run the assertions.
The mw.language singleton already has support for multiple languages,
and mediawiki.jqueryMsg already supports injecting data and constructing
new instances for each test case. Make use of that :)
Instead of calling ResourceLoaderLanguageDataModule::getData by
trying to hot load the same module repeatedly from load.php,
just export this data using 'packageFiles'.
The mediawiki.jqueryMsg QUnit suite previously took 4s to run locally
and now only 0.1s (145ms). This is not only significant for this
particular module, but also for QUnit in general as Headless Chrome
only took about 7s to run all of MediaWiki core's test suites prior
to this change, which is now down to ~3s. (MacBook Pro)
For WMF CI:
* Before (master commit):
- mediawiki.jqueryMsg.test: ~2.1s (2135ms)
- MediaWiki core total: ~4.8s
* After (this patch):
- mediawiki.jqueryMsg.test: ~0.015s (15ms)
- MediaWiki core total: ~3.6s
Bug: T250045
Bug: T225730
Change-Id: I5f1067feb0a43d63bfc5e7fff5110285a5e433c8
|
