---
title: WebRender
slug: 质量保证/WebRender
translation_of: Mozilla/QA/WebRender
---
<p>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.</p>

<p>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 <a href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&amp;component=Graphics%3A%20WebRender">Core :: Graphics: WebRender</a> component.</p>

<h2 id="WebRender">WebRender</h2>

<p>The WebRender suite has one linting job, <code>WR(tidy)</code>, and a <code>WR(wrench)</code> test job per platform. Generally these test jobs are only run if code inside the <code>gfx/wr</code> subtree are touched, although they may also run if upstream files they depend on (e.g. docker images) are modified.</p>

<h3 id="WRtidy">WR(tidy)</h3>

<p>The tidy lint job basically runs the <code>servo-tidy</code> tool on the code in the <code>gfx/wr</code> 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:</p>

<pre class="notranslate">cd gfx/wr
pip install servo-tidy
servo-tidy
</pre>

<p>To run on tryserver, use <code>./mach try fuzzy</code> and select the <code>webrender-lint-tidy</code> job.</p>

<h3 id="WRwrench">WR(wrench)</h3>

<p>The exact commands run by this test job vary per-platform. Generally, the commands do some subset of these things:</p>

<ul>
 <li>build the different webrender crates with different features enabled/disabled to make sure they build without errors</li>
 <li>run <code>cargo test</code> to run the built-in rust tests</li>
 <li>run the reftests to ensure that the rendering produced by WebRender matches the expectations</li>
 <li>run the rawtests (scenarios hand-written in Rust code) to ensure the behaviour exhibited by WebRender is correct</li>
</ul>

<h4 id="Running_locally_Desktop_platforms">Running locally (Desktop platforms)</h4>

<p>The test scripts can be found in the <code>gfx/wr/ci-scripts/</code> folder and can be run directly from the <code>gfx/wr</code> 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 <code>brew install cmake pkg-config</code> in order to get additional dependencies needed for building osmesa-src.</p>

<pre class="notranslate">cd gfx/wr
ci-scripts/linux-debug-tests.sh # use the script for your platform as needed
</pre>

<p>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 <code>reftests/text</code> 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.</p>

<h4 id="Running_locally_Android_emulatordevice">Running locally (Android emulator/device)</h4>

<p>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 <code><a href="https://hg.mozilla.org/mozilla-central/file/tip/gfx/wr/wrench/android.txt">gfx/wr/wrench/android.txt</a></code> file.</p>

<h4 id="Running_on_tryserver">Running on tryserver</h4>

<p>To run on tryserver, use ./mach try fuzzy and select the appropriate <code>webrender-&lt;platform&gt;-(release|debug)</code> job.</p>