mediawiki.jqueryMsg: Refactor "Match PHP parser" test suite
authorTimo Tijhof <krinklemail@gmail.com>
Thu, 12 Feb 2015 04:51:58 +0000 (04:51 +0000)
committerTimo Tijhof <krinklemail@gmail.com>
Thu, 12 Feb 2015 06:42:42 +0000 (06:42 +0000)
commit365b6f3af90e05be13c63d9e5ac8223c7e4f344b
tree1414b6aefaaa33884143828ecaba4a8c39056922
parentb3fb5933dd6a616006a001e589e478e8936dc43c
mediawiki.jqueryMsg: Refactor "Match PHP parser" test suite

Previously it was doing quite a few things wrong:

* Tests could potentially run in parallel. This was somewhat
  obscured by the asynchronous getMwLanguage() call being inside
  the synchronous each() loop. As such it basically first fired off
  the requests, and then handled them as they came back. They
  pretty much always come back in order (lucky) so the tests pass,
  but it was fragile.

* By default, jQuery.ajax() appends a cache buster ("&_{random}" query string)
  to requests with dataType 'script'. Disable this by setting cache=true.

Also:
* Store Promise objects instead of a low-level Callbacks list so that we don't
  have to wrap it. Instead, we simply chain from the $.ajax() promise, and use
  then() to feed the value instead of calling resolve() or fire().
* Use hasOwn() as extra sanity check (in case a random browser's non-standard
  Object.prototype methods match one of our non-standard language codes).
* Remove dead code "mw.messages.set( test.message )". This object has no message
  property (or anything else that it could be mistaken for). It just performs
  15 no-op in a loop. Follows-up 261aac63ec0777d6.

While the requests happen to (almost) always arrive in order, them running in
parallel put a lot of pressure on slow VMs using SQLite databases (which are
I/O bound). This causes a lock when queries from different processes overlap.

Change-Id: I0c5064780f80e1ddcc58ce32c390b2639b1f1ab6
tests/qunit/suites/resources/mediawiki/mediawiki.jqueryMsg.test.js