Bug 1839262 converted the gtest harness to use raw subprocess, but we can get
the same functionality more simply now with mozprocess.run_and_wait.
Differential Revision: https://phabricator.services.mozilla.com/D185208
In FOG::GetSingleton(), RunOnShutdown() sets up ShutdownPhase::XPCOMShutdown to
shut down glean through glean::impl::fog_shutdown().
Without this patch, when initialized directly through glean::impl::fog_init(),
nothing calls fog_shutdown(). With the gtest death test that runs through the
shutdown sequence (and exits) in D174094, glean then leaks a "glean.upload"
thread, leading to a permorange.
Differential Revision: https://phabricator.services.mozilla.com/D175454
Gtest checks (with ASSERT_* or EXPECT_* macros) in gtest death test child
processes are usually ignored with no way of manually enabling them.
This patch implements a helper class, ScopedTestResultReporter, that when it is
the current test reporter will print TestPartResults to stderr. Stderr of a
death test child process will get printed by the parent only if the testcase
failed. A death test child can only signal to the parent to fail the testcase
by means of the exit code (or the absence of exit). To help signal an
unexpected exit code, ScopedTestResultReporter can be made to exit the process
automatically as it goes out of scope, using different exit codes depending on
the death test child's test status where 0=pass, 1=nonfatal failure, and
2=fatal failure.
Note that when used like this, the death test parent process must be set up to
expect an exit code of 0 from the death test child process, typically through
`EXPECT_EXIT(DoTestThatExits(), testing::ExitedWithCode(0), "");`.
When an `EXPECT_EXIT` check fails, gtest makes sure to print stderr from the
child process with the unexpected exit code (which is where the test results
passed through ScopedTestResultReporter were printed).
Differential Revision: https://phabricator.services.mozilla.com/D175139
In FOG::GetSingleton(), RunOnShutdown() sets up ShutdownPhase::XPCOMShutdown to
shut down glean through glean::impl::fog_shutdown().
Without this patch, when initialized directly through glean::impl::fog_init(),
nothing calls fog_shutdown(). With the gtest death test that runs through the
shutdown sequence (and exits) in D174094, glean then leaks a "glean.upload"
thread, leading to a permorange.
Differential Revision: https://phabricator.services.mozilla.com/D175454
Gtest checks (with ASSERT_* or EXPECT_* macros) in gtest death test child
processes are usually ignored with no way of manually enabling them.
This patch implements a helper class, ScopedTestResultReporter, that when it is
the current test reporter will print TestPartResults to stderr. Stderr of a
death test child process will get printed by the parent only if the testcase
failed. A death test child can only signal to the parent to fail the testcase
by means of the exit code (or the absence of exit). To help signal an
unexpected exit code, ScopedTestResultReporter can be made to exit the process
automatically as it goes out of scope, using different exit codes depending on
the death test child's test status where 0=pass, 1=nonfatal failure, and
2=fatal failure.
Note that when used like this, the death test parent process must be set up to
expect an exit code of 0 from the death test child process, typically through
`EXPECT_EXIT(DoTestThatExits(), testing::ExitedWithCode(0), "");`.
When an `EXPECT_EXIT` check fails, gtest makes sure to print stderr from the
child process with the unexpected exit code (which is where the test results
passed through ScopedTestResultReporter were printed).
Differential Revision: https://phabricator.services.mozilla.com/D175139
Do not wait for gtest process completion in mozdevice; instead, rely
on existing gtest support for waiting for process completion.
The mozdevice no-wait code was broken; fixed here.
Differential Revision: https://phabricator.services.mozilla.com/D160321
Following a gtest timeout, signal the process to generate a minidump, then
dump the crash report to the test log, just like the existing timeout
handling for mochitest, reftest, etc.
This makes no changes for Android; it was already working.
Differential Revision: https://phabricator.services.mozilla.com/D160249
These helpers are inspired by the gtest-provided
{ASSERT,ENSURE}_HRESULT_{SUCCEEDED,FAILED} macros.
These are intended as replacements for patterns like
ENSURE_TRUE(NS_SUCCEEDED(rv)) which will actually report the encountered
nsresult error code code when they fail.
Differential Revision: https://phabricator.services.mozilla.com/D157213
The fact that the test runner app is defined inside the geckoview test package
has always felt like a hack to me. I've mistakenly thought that
TestRunnerActivity was used in GeckoView's junit tests many times (even though
that's not the case).
From what I can see, there's no way to generate an AAB package for androidTest,
so to be able to run Gecko tests as AAB we finally need to define the
TestRunner as an ordinary package instead.
Differential Revision: https://phabricator.services.mozilla.com/D127320
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650