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/
 * direct link to ongoing MW test status
 * For core modules a cronjob automatically populates tests under user MediaWiki (previously (pre-), KrinkleBot).

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.