The WebRender class of tests are used to test the WebRender module (lives in gfx/wr) in a standalone way, without being pulled into Gecko. WebRender is written entirely in Rust code, and has its own test suites.
If you are having trouble with these test suites please contact :kats or somebody else on the Graphics team (#gfx on IRC or Slack) and they will be able to point you in the right direction. Bugs against these test suites should be filed in the Core :: Graphics: WebRender component.
The WebRender suite has one linting job, WR(tidy)
, and a WR(wrench)
test job per platform. Generally these test jobs are only run if code inside the gfx/wr
subtree are touched, although they may also run if upstream files they depend on (e.g. docker images) are modified.
The tidy lint job basically runs the servo-tidy
tool on the code in the gfx/wr
subtree. This tool checks a number of code style and licensing things, and is good at emitting useful error messages if it encounters problems. To run this locally, you can do something like this:
cd gfx/wr pip install servo-tidy servo-tidy
To run on tryserver, use ./mach try fuzzy
and select the webrender-lint-tidy
job.
The exact commands run by this test job vary per-platform. Generally, the commands do some subset of these things:
cargo test
to run the built-in rust testsThe test scripts can be found in the gfx/wr/ci-scripts/
folder and can be run directly from the gfx/wr
folder if you have the prerequisite tools (compilers, libraries, etc.) installed. If you build mozilla-central you should already have these tools. On MacOS you may need to do a brew install cmake pkg-config
in order to get additional dependencies needed for building osmesa-src.
cd gfx/wr ci-scripts/linux-debug-tests.sh # use the script for your platform as needed
Note that when running these tests locally, you might get small antialiasing differences in the reftests, depending on your local freetype library. This may cause a few tests from the reftests/text
folder to fail. Usually as long as they fail the same before/after your patch it shouldn't be a problem, but doing a try push will confirm that.
To run the wrench reftests locally on an Android platform, you have to first build the wrench tool for Android, and then run the mozharness script that will control the emulator/device, install the APK, and run the reftests. Steps for doing this are documented in more detail in the gfx/wr/wrench/android.txt
file.
To run on tryserver, use ./mach try fuzzy and select the appropriate webrender-<platform>-(release|debug)
job.