Topic on Manual talk:JavaScript unit testing/Flow

Flexibility, environment and extension hook

Right now there's three factors that need some love that need to be fixed in the medium-long term. These are the:

• Flexibility of the test suite
  • Currently not so due to hardcoding in index.html
  • And will remove the need to keep track of dependancies
• Environment of the test suite
  • Right now there are no portals, tabs, bodyContent etc.
• Extensions
  • Extensions should be able load their modules in the test suite, and add a test suite for them

The way I'm planing to do this is by a SpecialPage. There would be a global variable (perhaps a hook is better / less evil regarding the killing of globals), that keeps track of where files containing test suites are located, and which module they test.

The SpecialPage would output the structure for QUnit (simple html snippet) and perhaps a self-submitting dropdown menu with available skins (submitting through GET as useskin), just like the SpecialBlankpage/"mwutiltest" hack had before I removed it. This in order to verify functions work in other layouts as well.

Also, this SpecialPage must unload all modules added before OutputPage->addModules to avoid conflicts with gadgets, user scripts and (parts of) extension modules, and only load the ones that have a test suite.

Issues

The main reason I didn't do this initially and went for a static html file is devided:

• It was a rushed proof-of-concept for the Berlin hackathon
• The mw.loader object needs to be tested as well, (read below), which means we need a more neutral environment anyway (atleast for those tests)
• The way the TestSwarm is currently set up it must work directly from an svn checkout. This isn't the case if there's a Special page that needs load.php to work and what not. This means there's a database needed and an otherwise "installed" MediaWiki instance.

mw.loader

The way we unit test the loader (currently it doesn't have that many tests but this is expected to grow in the future) must (obviously) not depend on itself. So we can either:

• keep the static index.html file but only for the loader
• or, we give our SpecialPage a mode in which, instead of unloading all added modules and adding our own, we add good old <script> tags to jquery.js and mediawiki.js from /resources and mediawiki.test.js from <ttt>tests/qunit/

I think the latter is the better option but would need a few changes in OutputPage probably.

TestSwarm

As mentioned, right now our TestSwarm configuration checks out /resources and /tests/qunit and adds a job for each test suite to http://mediawiki-testswarm/r12345/tests/qunit/index.html?filter=testmodulename.

In order to make this work from a SpecialPage the wiki needs to be installed, which also means a much larger check out. And due to TestSwarms nature of keeping (almost) all revisions[1] (which is a good thing), it may become very big.

Then we'd probably do a one-time install with a config we want (ie. private/read-only) and make the update/check/svn-co script in such a way that it will alias or copy the LocalSettings.php file to the directory. We may also need an .htaccess to hide the rest of the wiki.

Alright, done. --
Flushed 3,415 bytes of English from Krinkle's brain

---

1. ↑ all, as in, all revisions it checks out. It only checks out if the revision touched /resources or /tests/qunit