Make the test paths relative to topsrcdir before passing them to
TestResolver. Also do not passing cwd to TestResolver since it will
filter out tests that do not live under the directory where the mach
command is executed.
Verification steps:
Execute a mach test command from any subdirectory. For example:
$ cd testing/tps/
$ ../../mach xpcshell-test ../../services/fxaccounts/tests/xpcshell/
$ ../../mach test ../../services/fxaccounts/tests/xpcshell/
A subsequent patch will have another mach command dispatch into
`xpcshell-test`. To avoid redundant resolution of test paths, we now
support passing resolved test objects into the mach command.
--HG--
extra : rebase_source : 1eb0e7b1ef1e45ca163ddb152d1bbb7b6b4d02e6
Previously, mach xpcshell-test and mochitest-* were limited to a single
test "path" argument. This patch enables multiple arguments to be passed
in.
TestResolver in the build system has gained the ability to process
multiple paths in a single invocation. The mach commands have been
modified to utilize this new feature.
Only mach code paths that pass manifestdestiny.TestManifest instances
into the test runner can accept multiple arguments. This is because
there is no other way to pass a custom set of tests into the test
runner. If multiple test arguments are used but not supported, a warning
is emitted.
--HG--
extra : rebase_source : 1ce1328a969f654e7b43a7a0bdd15ed86f5ceb21
Manifests are now the mechanism used to specify how to run xpcshell
tests. This patch removes old code paths that allowed directories to be
specified.
runxpcshelltests.py still contains references to "testdirs." These
should likely be removed as well. This patch doesn't touch them out of
fear it may have consequences on automation.
--HG--
extra : rebase_source : 8cbfe6dc759dc0a311669c4fcba08ff7a60edc4a
extra : amend_source : 890377d9ba33d52c84e0736b0812231f3005b253
At the moment, the --debug argument accepted by mach xpcshell-test is
dropped. I don't know if just bringing the old harness's command-line
arguments forward to 'mach xpcshell-test' is the most mach-ish way to do
things, but it does let me get things started.
Previously we were tighly coupled with MozbuildObject. This was not in
the spirit of mach being a generic tool. Now, instead of passing multiple
arguments to __init__ of the class providing the mach command we either
pass 0 or 1. The number of arguments is detected when processing the
@CommandProvider decorator. The optional argument is a named tuple
containing mach run-time state.
Capturing of mach command provider information is now captured in a
class (as opposed to an anoymous tuple). We also capture these in a rich
data structure which is passed as part of the run-time data to the
command provider class. This allows mach commands to inspect the mach
environment.
Mach decorators have been moved to mach.decorators. mach.base is
reserved for generic mach data/container classes.
Existing mach command classes derived from MozbuildObject have been
replaced with either object or mozbuild.base.MachCommandBase. This
latter class translates the mach context instance passed to __init__
into the constructor arguments for MozbuildObject.__init__.
Support for registering function handlers with mach has been removed.
All handlers must be inside classes.
--HG--
rename : python/mach/mach/base.py => python/mach/mach/decorators.py
The code interacting with the test runners now resides in closer
proximity to the code it is invoking. We also purge testing
functionality from mozbuild, which is where it never really belonged.
--HG--
rename : python/mozbuild/mozbuild/testing/reftest.py => layout/tools/reftest/mach_commands.py
rename : python/mozbuild/mozbuild/testing/mochitest.py => testing/mochitest/mach_commands.py
rename : python/mozbuild/mozbuild/testing/xpcshell.py => testing/xpcshell/mach_commands.py
