So far we've still been using ./tests/qunit/index.html in TestSwarm, today I've tested locally
to submit a url to SpecialJavaScriptTest instead and made a bunch of browsers join my swarm,
quite a few problems popped up. This commit fixes those issues so that we can actually use
SpecialJavaScriptTest in TestSwarm.
* Add QUnit configuration variable for TestSwarm's inject.js
In order to use TestSwarm, the urls that TestSwarm loads in clients that has
the QUnit test suite running on it need to include a little javascript.
This inject.js registers hooks with QUnit to listen for when the test suite finishes
and contacts the parent window (TestSwarm loads the qunit test suite url in an iframe)
to submit the results. Previously I included a copy of TestSwarm's inject.js in
./tests/qunit/data and in our testrunner.js a relative link to that.
However this is currently breaking because it is an outdated version. Updating brings
no good since someone else might use their own TestSwarm would could still run on an old
version etc. The TestSwarm submitted too always expects that it's own inject.js is used,
not some snapshot copy. I've removed the copy of it in MediaWiki and instead added a
configuration option to point to wherever the you want is located.
Also, since the old static index.html version of the unit test can't retrieve PHP based
content, this means TestSwarm submissions through the old static index.html are no longer
supported. Only through the new Special:JavaScriptTest from now on. I'll probably remove
the whole index.html soon-ish as it's getting quite annoying to maintain all that by hand,
and it's been superseded in everywhere imaginable now anyway. Even not used anymore by
intergration.mediawiki.org because that's been quiet since the Git-switchover.., and when
we update it, we can update it to point to the new SpecialPage instead.
* OutputPage::allowClickjacking() on SpecialJavaScriptTest/qunit.
When initially testing the TestSwarm setup to submit SpecialJavaScriptTest/qunit urls
(instead of the old ./tests/qunit/index.html) it was failing due to an iframe DENY.
This was a bit odd since `$wgBreakFrames = false;` by default, and although
`$wgEditPageFrameOptions = 'DENY';` by default, it wasn't obvious at all that that value
("DENY") is used for all OutputPages by default (as supposed to just action=edit and the
like). This is because OutputPage has mPreventClickjacking=true by default and when it's
true-ish it uses $wgEditPageFrameOptions for the X-Frame-Options.
* 'position' => true; for the mediawiki.tests.qunit.suites module.
QUnit has a hook for "done". Which is called when QUnit.start() is called and all queued tests
have been executed. QUnit.start() is automatically called on window.onload by QUnit.
TestSwarm uses QUnit's hook system to hook into the QUnit "done" event, and at that point
takes the stats, submits them to TestSwarm and go on with the next job.
When testing locally, I got semi-random failures reporting that only 0/0 tests were
successfully ran in IE6. This is because when QUnit.start (and consequently QUnit.done)
are first called, apparently no test suites had finished downloading and/or execution yet
(the bottom queue is asynchronous, and doesn't postpone domready nor window.onload).
When normally viewing Special:JavaScriptTest/qunit this doesn't break anything, because if
QUnit start/done is in the past and another module(), test(), or equal() etc. is called it just
picks up again and adds more results to the page and calls QUnit.done() again.
However in the case of the TestSwarm embed, it submits the results after the first done() and
cleans up the iframe. So I'm making mediawiki.tests.qunit.suites a blocking module instead, so
that there will only be one QUnit.start/done and that's the one that TestSwarm gets and after
which TestSwarm can safely garbage the iframe.
This means that basically all test suite modules and the original modules they are testing will
be loaded from the head. Shouldn't have any side effects, but might cause minor breakage in
future in modules that badly assume they're being put on the bottom.
I'm not considering that a bug in the test, it'll just help catch that bad code sooner :),
it's a test suite after all.
(Yay, my first Git commit to MediaWiki core)
Change-Id: I83f83377f2183b6deb4e901af602ac9a5628558b
* Through all QUnit updates, the html was never updated (only the JS/CSS files). Updating html now according to QUnit documentation. (introduced a new html element used for adding test document elements which are automatically cleaned up. the JS/CSS for QUnit was already referring to this but silently failing)
* wrapSummaryHTML() now really need one of three states or an exception
is thrown.
* Moved a parameter incorrectly passed to addHtml() up to the previous
wrapSummaryHtml() code. Per CR on r107919
Changed written by Timo and reviewed by Hashar. This should be harmless.
To enable the feature:
$wgEnableJavaScriptTest = true;
Then head to:
[[Special:JavaScriptTest/qunit]]
