wiki.techinc.nl/tests/qunit/data/generateJqueryMsgData.php

96 lines
2.7 KiB
PHP
Raw Normal View History

<?php
/**
* This PHP script defines the spec that the mediawiki.jqueryMsg module should conform to.
*
* It does this by looking up the results of various kinds of string parsing, with various
* languages, in the current installation of MediaWiki. It then outputs a static specification,
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
* mapping expected inputs to outputs, which is used then run by QUnit.
*/
require __DIR__ . '/../../../maintenance/Maintenance.php';
class GenerateJqueryMsgData extends Maintenance {
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
private static $keyToTestArgs = [
'undelete_short' => [
[ 0 ],
[ 1 ],
[ 2 ],
[ 5 ],
[ 21 ],
[ 101 ]
],
'category-subcat-count' => [
[ 0, 10 ],
[ 1, 1 ],
[ 1, 2 ],
[ 3, 30 ]
]
];
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
private static $testLangs = [ 'en', 'fr', 'ar', 'jp', 'zh', 'nl', 'ml', 'hi' ];
public function __construct() {
parent::__construct();
$this->addDescription( 'Create a specification for message parsing ini JSON format' );
// add any other options here
}
public function execute() {
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
$data = $this->getData();
$this->writeJsonFile( $data, __DIR__ . '/mediawiki.jqueryMsg.data.json' );
}
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
private function getData() {
$messages = [];
$tests = [];
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
$jsData = [];
foreach ( self::$testLangs as $languageCode ) {
$jsData[$languageCode] = ResourceLoaderLanguageDataModule::getData( $languageCode );
foreach ( self::$keyToTestArgs as $key => $testArgs ) {
foreach ( $testArgs as $args ) {
// Get the raw message, without any transformations.
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
$template = wfMessage( $key )->useDatabase( false )
->inLanguage( $languageCode )->plain();
// Get the magic-parsed version with args.
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
$result = wfMessage( $key, ...$args )->useDatabase( false )
->inLanguage( $languageCode )->text();
// Record the template, args, language, and expected result
// fake multiple languages by flattening them together.
$langKey = $languageCode . '_' . $key;
$messages[$langKey] = $template;
$tests[] = [
'name' => $languageCode . ' ' . $key . ' ' . implode( ',', $args ),
'key' => $langKey,
'args' => $args,
'result' => $result,
'lang' => $languageCode
];
}
}
}
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
return [
'messages' => $messages,
'tests' => $tests,
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
'jsData' => $jsData,
];
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
}
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
private function writeJsonFile( array $data, $dataSpecFile ) {
$phpParserData = [
'@' => 'Last generated with ' . basename( __FILE__ ) . ' at ' . gmdate( 'r' ),
] + $data;
mediawiki.jqueryMsg: Refactor test suite to not make any API requests 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
2019-10-04 18:49:07 +00:00
$output = FormatJson::encode( $phpParserData, true ) . "\n";
$fp = file_put_contents( $dataSpecFile, $output );
if ( $fp === false ) {
die( "Couldn't write to $dataSpecFile." );
}
}
}
$maintClass = GenerateJqueryMsgData::class;
require_once RUN_MAINTENANCE_IF_MAIN;