Last modified: 2011-05-22 16:20:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T30915, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28915 - Implement QUnit Test Suite for MediaWiki JS
Implement QUnit Test Suite for MediaWiki JS
Status: VERIFIED FIXED
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Krinkle
:
Depends on:
Blocks: 26908
  Show dependency treegraph
 
Reported: 2011-05-10 19:32 UTC by Krinkle
Modified: 2011-05-22 16:20 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2011-05-10 19:32:17 UTC
(copied from bug 26908 comment 8)

Here's a few points (likely in this order, but some may be re-ordered, postponed or or skipped)

== Init QUnit ==

Point 1a: Add QUnit as a module in core
Point 1b: Look over modules prepare where needed to be more easily
testable (ie. functions that should but don't have a return values. like mw.config.set which can fail or succeed, this is tested but nothing returned..)

Point 2: Create a basic (neutral) environment where QUnit will be running.

Point 3: Go through core modules created/maintained by Wikimedia developers (mediawiki.js, jquery.client.js, .. but not jquery.cookie). Review line by line, and make sure there's suffecient test suits for everything.

== Extend / Integrate QUnit ==

Point 4: Create a nice way for extensions to state that a module should be
loaded on Unit-test page and register a js file with qunit tests which should
be executed.

Point 5: Figure out what needs to be done to make a QUnit test page into a
TestSwarm-able thing through SVN sending periodic tests to clients  – without
requiring users to have a TestSwarm - a vanilla QUnit page should stay
available.

== Distributed javascript testing / aka TestSwarm compatibility ==

Point 6: Set up a local TestSwarm

Point 7: Set up at Toolserver (if possible).

== Wikimedia ==

* Install somewhere in WMF (probably a wmf-like wiki running trunk, perhaps
multiple wikis (one on trunk, one of wmfbranch) see [1])

Point 10: IRC Bot reporting breakages ?


--
Krinkle

[1] http://www.mediawiki.org/wiki/WMF_Projects/Virtualization_cluster
Comment 1 Krinkle 2011-05-10 21:57:06 UTC
Point 1a done in r87848.
Comment 2 Krinkle 2011-05-12 01:36:13 UTC
More of Point 1, 2 and 3 tackled in r87898.
Comment 3 Michael Dale 2011-05-16 13:25:39 UTC
per r87898 and r87848...  We probably want to reorganize this a bit. In extensions and up-until-now in core all tests go into the /tests folder. 

Probably something like phase3/tests/qunit would be a good place to put qunit tests. Inside the qunit folder you can mirror the directory structure of resources ( like phpunit folder does it )  

If you want to avoid hitting mediaWiki php, you could put a RunQUnitTests.html in the root test folder ( similar to the RunQUnitTests.html ). Yes you would have to check out two folders from mediawiki to run these tests for testSwarm, but if you use relative paths it should work in both development and testSwarm. 

Likewise we could "manually" add extensions to testSwarm testing, if they had a consistent location relative to the mediawiki root.
Comment 4 Krinkle 2011-05-22 10:04:05 UTC
r88431: QUnit reorganization (among other things moved the QUnit directory from /resources/test/ to /tests/qunit/)
Comment 5 Krinkle 2011-05-22 10:04:29 UTC
Marking fixed as the implementation and compatibility with TestSwarm is ready now.
Comment 6 Antoine "hashar" Musso (WMF) 2011-05-22 16:20:50 UTC
Thanks a ton Krinkle!!

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links