When running mochitests in automation, we expect no more than 1 instance of
Firefox to be running at any time: the browser under test. In local testing
scenarios, additional browser instances might be running.
Warn when mochitests find additional 'firefox' instances running before launching
a browser for testing, to make it easier to detect anomalies in automation.
This patch also checks for I/O errors when deleting leftover crashdump files
in the test harness and reports them if the files couldn't be deleted. This
won't prevent tests from leaking crash dumps if they're not written correctly,
but it will make their presence visible and won't cause the harness to hang if
it cannot delete them.
MozReview-Commit-ID: FLvBJxEKkH5
--HG--
extra : rebase_source : 6a0242b670ceabc2307c5345b0ea7108857a10d2
extra : source : 95b1010395826d06cdc77cbf43faf7d8681504eb
mochitests needs access to TESTING_JS_MODULES which are installed in $(OBJDIR)\_tests\modules\
MozReview-Commit-ID: CMgDlj4uKeP
--HG--
extra : rebase_source : 0a32b71db56bd68fc369d58117075dabf0465727
The TestMetadata and TestResolver classes aren't technically part of the build
system. The only connection is that they consume some build system output.
The next patch in this series is going to be merging in a bunch of other test
resolving logic from other parts of the tree. Moving this out first allows us
to keep that extra logic out of mozbuild.
MozReview-Commit-ID: 1eq4SjFVCyW
--HG--
rename : python/mozbuild/mozbuild/test/test_testing.py => testing/mozbase/moztest/tests/test_resolve.py
extra : rebase_source : 7ff11f9ec455547533082d20cb5371845f7a4f21
This adds a global instance that can be used by invoking assertion methods directly on the imported Assert object. The test suites set the global reporter function to the one for the currently running test.
MozReview-Commit-ID: 8dksVc9o7r
--HG--
extra : rebase_source : 3e382c6d24c6019d29963811c37469cfc23b928f
This patch includes a bunch of somewhat related fixes, these are:
- Ensuring that when a mochitest calls SimpleTest.expectChildProcessCrash()
the harness will wait for the crashes to be recorded before deleting the
dump files. This involves a message round-trip between the content and
parent process so to minimize its performance impact on all the non-crashing
tests it is done only when required.
- As an additional optimization, the SimpleTest harness will not send a
message to the content process anymore whenever it receives an
ipc:content-shutdown event, instead it does it only for abnormal shutdowns.
- Manually fixing remaining mochitests causing crashes to wait for crashes to
be recorded before finishing and deleting the dump files.
- Modifying BrowserTestUtils.crashBrowser() so that it optionally does not
delete the dump files, this is useful for tests that submit their dumps and
thus delete them on their own.
MozReview-Commit-ID: 4SLJ8BjJ18n
--HG--
extra : source : b5452a41bb962c6929292c5c538e19ac28d84fe7
We are seeing failures starting websocketProcessBridge due to the port being
in use. It is most likely a previously started websocketProcessBridge process that
is using the port.
On Windows, mozprocess.kill() calls TerminateJobObject/TerminateProcess and
GetExitCodeProcess, but these are asynchronous and don't wait for the process to
actually exit. Adding a wait call should guarantee the process has exited before
continuing which will hopefully ensure the port is free by the time we start an
additional websocketProcessBridge.
MozReview-Commit-ID: HGyjEsy1Ons
--HG--
extra : rebase_source : f56034e1fc0febae07d9b2728eded0a48975baca
The goal is to use a newer Android-Gradle build plugin version (2.3.3
is latest stable). That requires a modern Gradle (anything 3.3+, but
3.4.1 is the default from my Android Studio), and also a newer
build-tools (25.0.3 is latest stable).
The locations of lint output changed, and we want to use the standard
output location because it's difficult to accommodate variant details
in custom names. We change the location of findbugs output to follow
suit.
This requires either:
- fixing lint errors
- adding to the lint whitelist
- using the new lint baseline
It's best to use the new lint baseline, which will happen in the next commit.
MozReview-Commit-ID: D19FzIDCJrE
--HG--
extra : rebase_source : 12d132c0c3e0dbe2b8873b31360ea96d612de44c