Currently code used by many mochitest-browser tests is scattered
throughout the tree in various head.js files. Many similar or identical
helper methods are repeated throughout these files.
This commit introduces a BrowserTestUtils.jsm module and includes it in
the mochitest scope; the idea being these frequently re-implemented
methods can live in a central place.
A TestUtils.jsm module has also been introduced to contain code useful to
all types of tests.
--HG--
extra : rebase_source : 7d22be6f800aa39bbddb976baa2ea7fdfb96a58b
This reworks how the Mochitest DOMWINDOW and DOCSHELL leak detector works. Rather than
collecting immediately in the top-level script, it sends a message to all processes
telling them to carry out collections. Each process prints out a message when it has
finished the collections. This message is used by the test harness to decide when windows
and docshells for that process should be have been destroyed.
In non-e10s mode, the shutdown leak detector is only run in the parent process, to work
around various issues with leak detection in the thumbnail process tests.
This reworks how the Mochitest DOMWINDOW and DOCSHELL leak detector works. Rather than
collecting immediately in the top-level script, it sends a message to all processes
telling them to carry out collections. Each process prints out a message when it has
finished the collections. This message is used by the test harness to decide when windows
and docshells for that process should be have been destroyed.
This introduces a new medule ContentTask, which includes a spawn method.
This new method can be used to spawn a task in the content process of a
browser. When called, a promise will be returned which resolves to the
value returned by the task.
This allows you to quickly write test code which can touch the content
and return information without having to write custom framescripts all
the time (The content code can be written inline as a simple generator
definition). ContentTask is automatically included in the scope of
mochitests.
An example use follows:
yield ContentTask.spawn(browser, {}, function* gen_replaceState() {
content.window.history.replaceState({}, "", 'test-entry/');
return "Value that the promise will resolve with";
});
--HG--
extra : rebase_source : 9b6ae71407da582cdaa8087b5e367c72fa08a337
Some mochitests needs to behave differently when ran on B2G Desktop.
Currently, this is implemented using user agent string detection,
mostly relying on "Mobile" being present and "Android" being absent.
This is only true on B2G Desktop when ran on Try because the mozconfig
defined FXOS_SIMULATOR and that, per bug 1115935, this substring is only
added in this case, but not if just MOZ_B2G is defined. A better
approach is to expose 'isB2G' in SpecialPowers for this kind of
detection.
This adds support for assertion checking in all mochitest suites except
for mochitest-browser-chrome. The checking works much like it does in
reftest, except for the mechanism for annotating expected assertions,
SimpleTest.expectAssertions() (see its in-code documentation).
The support is initially disabled in that:
(1) It doesn't cause the tests to report failure (and thus turn the
tree orange).
(2) It prints TEST-DETCEPXENU-FAIL/PASS instead of
TEST-UNEXPECTED-FAIL/PASS (so that it doesn't show up in log
highlighting).
The assertion checking only works within the test runner (which runs
multiple tests); it does not function when running only a single test.
