tests/README

   1 Outline of test categories:
   2
   3 The conform/ tests should be non-interactive unit-tests that verify a single
   4 feature is behaving as documented. See conform/ADDING_NEW_TESTS for more
   5 details.
   6
   7 The performance/ tests are performance tests, both focused tests testing single
   8 metrics and larger tests. These tests are used to report one or more
   9 performance markers for the build of Clutter. Each performance marker is picked
  10 up from the standard output of running the tests from strings having the form
  11 "\n@ marker-name: 42.23" where 'marker-name' and '42.23' are the key/value pairs
  12 of a single metric. Each test can provide multiple key/value pairs. Note that
  13 if framerate is the feedback metric the test should forcibly enable FPS
  14 debugging itself. The file test-common.h contains utility function helping to
  15 do fps reporting.
  16
  17 The interactive/ tests are any tests whose status can not be determined without
  18 a user looking at some visual output, or providing some manual input etc. This
  19 covers most of the original Clutter tests. Ideally some of these tests will be
  20 migrated into the conformance/ directory so they can be used in automated
  21 nightly tests.
  22
  23 The accessibility/ tests are tests created to test the accessibility support of
  24 clutter, testing some of the atk interfaces.
  25
  26 The data/ directory contains optional data (like images and ClutterScript
  27 definitions) that can be referenced by a test.
  28
  29 Other notes:
  30
  31 • All tests should ideally include a detailed description in the source
  32 explaining exactly what the test is for, how the test was designed to work,
  33 and possibly a rationale for the approach taken for testing.
  34
  35 • When running tests under Valgrind, you should follow the instructions
  36 available here:
  37
  38         http://live.gnome.org/Valgrind
  39
  40 and also use the suppression file available inside the data/ directory.