Manual:JavaScript unit testing

Unit testing in MediaWiki for its JavaScript code base is performed using the QUnit JavaScript Testing framework..

The unit tests are located in the tests/qunit directory. Tests are organized into a directory structure that matches the directory structure of the code that they are testing. For example: The unit tests for file resources/mediawiki.util/mediawiki.util.js can be found in tests/qunit/suites/resources/mediawiki.util/mediawiki.util.js.

Running the unit tests
Run the unit tests from the browser.
 * 1) Browse to.
 * 2) There's no step 2, sit back and wait.
 * 3) No. Not even step 3.



Completeness test
In order to enable completeness test plugin, set " " in the query string
 * Browse to.



Writing Unit Test for Modules

 * Todo

Write Testable Code

 * Still a work-in-progess

Return values
Functions should always have a return value. Not just "get"-like functions, but also (perhaps even more important) the "set"-like functions. Scripts may not use this return value in many cases (ie. it's out of their scope to do anything about it), but in more advanced structures or test suites, the return value of a "set" function is very important (ie. "don't load X if Y was not set", or "Did the function correctly refuse to do X in scenario Y").

Compare the following two functions Compared to:

The latter is much easier to verify. For example, in the above case, a key may not be a number (such as an array index key). So to test that it refuses to do so in QUnit:

TestSwarm

 * Todo

TestSwarm is a system to parcel out JavaScript-based tests to multiple browsers. As many folks can connect as desired, and tests will be automatically sent to whatever connected browser and recorded based on success and browser version etc. Because MediaWiki jobs submitted to TestSwarm are assigned to all the browsers we support at that time (even more rarely-used browsers, regardless of whether these are connected to the swarm when the commit is made), we can ensure that test coverage gets run on all of them, not just whatever a developer has handy when they make a commit.


 * On Toolserver: http://toolserver.org/~krinkle/testswarm/
 * MediaWiki commits to core modules and test suites (previously, pre-: here).

"Automated distributed continuous unit testing for JavaScript" (where QUnit="unit testing", and TestSwarm="Automated distribution, continuously.") However PHP is pretty much static/similar on all platforms. Which is why running PHPUnit on your localhost is enough to know that the code is good if (it passes the test). But due to cross-browser differences, running QUnit on your localhost in Firefox doesn't say all that much. That's why we need to run tests in all browsers we support (IE7,8,9, Firefox 3,4,5 etc.).
 * From conversation with Krinkle: "TestSwarm does this: It automatically checks out every new revision (related to js-resources) from SVN and then it sends them to different browsers to run the test and summarizes the results – in order to easily track if something brakes, and when it does we can see the exact revision in which the breakage started (even if new commits were made), and where (modulename and testfunction) of the breakage."
 * In a sentence, relation between QUnit and TestSwarm is:
 * It's a bit like CruiseControl_for_phpUnit ("Automated continues integration for PHP"), except for the "distribution" part. Which CruiseControl doesn't do, but also doesn't have to do, because:
 * Every browser is different in terms of how far and which version of the ECMAScript-specification was implemented (ie. JavaScript).
 * TestSwarm keeps track of which module in which revision is tested each of these browsers. And whenever a client connects TestSwarm sends tests that haven't been run in that svn-revision / browser-name-version combination yet.

Current Problems

 * The test runner page has no pointer to this documentation (added r88734; not pretty but at least it's in)
 * Test files often have the same name as the files they are testing, eg 'mediawiki.js' or 'jquery.colorUtil.js'. This makes code maintenance more difficult because bare filenames are often shown when navigating or working with code. Consider using the word 'test' visibly in the filename.
 * For instance, our phpunit test case files are almost always named by appending 'Test' to the tested class/file's name:
 * Block.php <-> BlockTest.php
 * IP.php <-> IPTest.php
 * Title.php <-> TitleTest.php
 * LanguageConverter.php <-> LanguageConverterTest.php
 * It looks like new test files must be manually added to index.html. Among other things this static list means that extensions cannot add test cases except by implementing a second test runner page?
 * Krinkle's got some ideas for this, but for now we're concentrating on the core tests which are all bundled together, so easy enough to work with in the meantime. For more info/discussion see this thread.