This allows running web-platform-tests on Fennec given a running emulator.
(Which is how we expect the tests to run in automation as well -- the
android_emulator_unittest mozharness script takes care of emulator
start-up.) It also hooks up ./mach wpt.
wptrunner sets up a profile for Fennec, forwards the marionette port
and starts up Fennec, etc.
= Usage =
Set your mozconfig to build fennec.
Start an emulator: `./mach android-emulator --version x86`
Install fennec: `./mach build && ./mach package && ./mach install`
Run the tests:
```
./mach wpt --product=fennec --testtype=testharness
--certutil-binary path/to/host/os/certutil path/to/some/tests
```
Differential Revision: https://phabricator.services.mozilla.com/D1587
Profiling shows that switching to this library means we no longer
spend most of the update time parsing json (vs 80% or so before),
making other optimisations worthwhile. This is never used in
automation (except wptsync) so availability of the library in the
internal pypi isn't a problem.
MozReview-Commit-ID: U5gabb5lz8
We try to find fix_macosx_stack.py on the wrong path, which leads us can't run
wpt tests without setting stack fix directory manually (--stackfix-dir).
In this patch, we fix this issue by pointing the path to @topobjdir/dist/bin.
MozReview-Commit-ID: 8JzWWgVM6fM
Upstream wpt changed from having a wptrun script to a wpt script with
a run subcommand. This involved some internal movement of code which
broke the `mach wpt` command when used with a non-firefox
product. This commit changes the mach integration to be compatible
with the new upstream API.
MozReview-Commit-ID: 1hvmZedNHSX
Ahem.ttf is copied to $(DIST)/bin/firefox/fonts, but this file is broken due to text mode copy. So we should use binary mode instead.
MozReview-Commit-ID: KP7yNyPiejU
Allow running |mach wpt| on one click loaners in order to run
web-platform-tests tests.
This implementation is just like the one for other testsuites using
thee packaged tests rather than the checkout that we get with wpt, at
least on Linux. That's also where the tests run from so it seems
reasonable for now. Moving to the checkout in the future could remove
some of the logic here by using a fake mozbuild environment so that
the testsuite itself doesn't have to implement anything much.
MozReview-Commit-ID: CaewrdjJ2ef
This ensures that developers can run the majority of tests with the
default config, but makes things a little more confusing for marionette
developers.
MozReview-Commit-ID: 9wd761ZgCyx
For Chrome and Edge we don't have any way to set the DNS configuration
to include web-platform.test, so we need to error if this isn't already set.
MozReview-Commit-ID: BHRsTiuV28x
Using the wptrun infrastructure from upstream, it is now posible to
make it easy to run web-platform-tests in other browsers. The syntax
used is
mach wpt --product [chrome|servo|edge] [tests]
This will try to use the selected product; possibly prompting to
install dependencies like the WebDriver implementation. For servo if
the install isn't on the PATH then --binary can be used to point to
the actual location.
Because manifest metadata is kept in the same directory as expectation
data and we don't want to reuse Firefox expectation data for other
browsers, a new products subdirectory is introduced and added to the
ignore files. This will contain a subdirectory for each product into
which a copy of the test manifest is placed. It may also be used to
store any expectation data for the other products, in the same way as
testing/web-platform/meta.
MozReview-Commit-ID: 8fdCnha5t2F
Using the wptrun infrastructure from upstream, it is now posible to
make it easy to run web-platform-tests in other browsers. The syntax
used is
mach wpt --product [chrome|servo|edge] [tests]
This will try to use the selected product; possibly prompting to
install dependencies like the WebDriver implementation. For servo if
the install isn't on the PATH then --binary can be used to point to
the actual location.
Because manifest metadata is kept in the same directory as expectation
data and we don't want to reuse Firefox expectation data for other
browsers, a new products subdirectory is introduced and added to the
ignore files. This will contain a subdirectory for each product into
which a copy of the test manifest is placed. It may also be used to
store any expectation data for the other products, in the same way as
testing/web-platform/meta.
MozReview-Commit-ID: 8fdCnha5t2F
Using the wptrun infrastructure from upstream, it is now posible to
make it easy to run web-platform-tests in other browsers. The syntax
used is
mach wpt --product [chrome|servo|edge] [tests]
This will try to use the selected product; possibly prompting to
install dependencies like the WebDriver implementation. For servo if
the install isn't on the PATH then --binary can be used to point to
the actual location.
Because manifest metadata is kept in the same directory as expectation
data and we don't want to reuse Firefox expectation data for other
browsers, a new products subdirectory is introduced and added to the
ignore files. This will contain a subdirectory for each product into
which a copy of the test manifest is placed. It may also be used to
store any expectation data for the other products, in the same way as
testing/web-platform/meta.
MozReview-Commit-ID: 8fdCnha5t2F
This fixes a bug on Windows where we try to append .exe to the path
and so get an invalid, non-existing path by using the Fx binary as the
path and then stripping off the filename.
MozReview-Commit-ID: 8EWGGcz40iw
This provides a simple way of creating a web-platform-test with all
the boilerplate added automatically. It also updates the manifest file
with the new test and opens it in the configured editor and source
build.
This removes ambiguity as to which modules are being imported, making
import slightly faster as Python doesn't need to test so many
directories for file presence.
All files should already be using absolute imports because mach command
modules aren't imported to the package they belong to: they instead
belong to the "mach" package. So relative imports shouldn't have been
used.
This extends the upstream update script with steps for pushing
local changes to upstream. The general approach is to look for all
commits to the tests directory since the last sync, rewrite those
so they apply to upstream at the last sync point, then rebase onto
the sync commit, before creating and merging a PR for each in turn.
