testing/docs/webrender/index.rst

   1 WebRender Tests
   2 ===============
   3
   4 The WebRender class of tests are used to test the WebRender module
   5 (lives in gfx/wr) in a standalone way, without being pulled into Gecko.
   6 WebRender is written entirely in Rust code, and has its own test suites.
   7
   8 If you are having trouble with these test suites, please contact the
   9 Graphics team (#gfx on Matrix/Element or Slack) and they will be able to
  10 point you in the right direction. Bugs against these test suites should
  11 be filed in the `Core :: Graphics: WebRender`__ component.
  12
  13 __ https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics%3A%20WebRender
  14
  15 WebRender
  16 ---------
  17
  18 The WebRender suite has one linting job, ``WR(tidy)``, and a
  19 ``WR(wrench)`` test job per platform. Generally these test jobs are only
  20 run if code inside the ``gfx/wr`` subtree are touched, although they may
  21 also run if upstream files they depend on (e.g. docker images) are
  22 modified.
  23
  24 WR(tidy)
  25 ~~~~~~~~
  26
  27 The tidy lint job basically runs the ``servo-tidy`` tool on the code in
  28 the ``gfx/wr`` subtree. This tool checks a number of code style and
  29 licensing things, and is good at emitting useful error messages if it
  30 encounters problems. To run this locally, you can do something like
  31 this:
  32
  33 .. code:: shell
  34
  35    cd gfx/wr
  36    pip install servo-tidy
  37    servo-tidy
  38
  39 To run on tryserver, use ``./mach try fuzzy`` and select the
  40 ``webrender-lint-tidy`` job.
  41
  42 WR(wrench)
  43 ~~~~~~~~~~
  44
  45 The exact commands run by this test job vary per-platform. Generally,
  46 the commands do some subset of these things:
  47
  48 -  build the different webrender crates with different features
  49    enabled/disabled to make sure they build without errors
  50 -  run ``cargo test`` to run the built-in rust tests
  51 -  run the reftests to ensure that the rendering produced by WebRender
  52    matches the expectations
  53 -  run the rawtests (scenarios hand-written in Rust code) to ensure the
  54    behaviour exhibited by WebRender is correct
  55
  56 Running locally (Desktop platforms)
  57 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  58
  59 The test scripts can be found in the ``gfx/wr/ci-scripts/`` folder and
  60 can be run directly from the ``gfx/wr`` folder if you have the
  61 prerequisite tools (compilers, libraries, etc.) installed. If you build
  62 mozilla-central you should already have these tools. On MacOS you may
  63 need to do a ``brew install cmake pkg-config`` in order to get
  64 additional dependencies needed for building osmesa-src.
  65
  66 .. code:: shell
  67
  68    cd gfx/wr
  69    ci-scripts/linux-debug-tests.sh # use the script for your platform as needed
  70
  71 Note that when running these tests locally, you might get small
  72 antialiasing differences in the reftests, depending on your local
  73 freetype library. This may cause a few tests from the ``reftests/text``
  74 folder to fail. Usually as long as they fail the same before/after your
  75 patch it shouldn't be a problem, but doing a try push will confirm that.
  76
  77 Running locally (Android emulator/device)
  78 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  79
  80 To run the wrench reftests locally on an Android platform, you have to
  81 first build the wrench tool for Android, and then run the mozharness
  82 script that will control the emulator/device, install the APK, and run
  83 the reftests. Steps for doing this are documented in more detail in the
  84 ``gfx/wr/wrench/android.txt`` file.
  85
  86 Running on tryserver
  87 ^^^^^^^^^^^^^^^^^^^^
  88
  89 To run on tryserver, use ``./mach try fuzzy`` and select the appropriate
  90 ``webrender-<platform>-(release|debug)`` job.