b5a7657076
This makes a start on porting the Cogl conformance tests that currently still live in the Clutter repository to be standalone Cogl tests that no longer require a ClutterStage. The main thing is that this commit brings in is the basic testing infrastructure we need, so now we can port more and more tests incrementally. Since the test suite wants a way to synchronize X requests/replies and we can't simply call XSynchronize in the test-utils code before we know if we are really running on X this adds a check for an environment variable named "COGL_X11_SYNC" in cogl-xlib-renderer.c and if it's set it forces XSynchronize (dpy, TRUE) to be called. By default the conformance tests are run off screen. This makes the tests run much faster and they also don't interfere with other work you may want to do by constantly stealing focus. CoglOnscreen framebuffers obviously don't get tested this way so it's important that the tests also get run on screen every once in a while, especially if changes are being made to CoglFramebuffer related code. On screen testing can be enabled by setting COGL_TEST_ONSCREEN=1 in your environment.
64 lines
2.7 KiB
Plaintext
64 lines
2.7 KiB
Plaintext
Outline of test categories:
|
|
|
|
The conform/ tests:
|
|
-------------------
|
|
These tests should be non-interactive unit-tests that verify a single
|
|
feature is behaving as documented. See conform/ADDING_NEW_TESTS for more
|
|
details.
|
|
|
|
Although it may seem a bit awkward; all the tests are built into a
|
|
single binary because it makes building the tests *much* faster by avoiding
|
|
lots of linking.
|
|
|
|
Each test has a wrapper script generated though so running the individual tests
|
|
should be convenient enough. Running the wrapper script will also print out for
|
|
convenience how you could run the test under gdb or valgrind like this for
|
|
example:
|
|
|
|
NOTE: For debugging purposes, you can run this single test as follows:
|
|
$ libtool --mode=execute \
|
|
gdb --eval-command="b test_cogl_depth_test" \
|
|
--args ./test-conformance -p /conform/cogl/test_cogl_depth_test
|
|
or:
|
|
$ env G_SLICE=always-malloc \
|
|
libtool --mode=execute \
|
|
valgrind ./test-conformance -p /conform/cogl/test_cogl_depth_test
|
|
|
|
By default the conformance tests are run offscreen. This makes the tests run
|
|
much faster and they also don't interfere with other work you may want to do by
|
|
constantly stealing focus. CoglOnscreen framebuffers obviously don't get tested
|
|
this way so it's important that the tests also get run onscreen every once in a
|
|
while, especially if changes are being made to CoglFramebuffer related code.
|
|
Onscreen testing can be enabled by setting COGL_TEST_ONSCREEN=1 in your
|
|
environment.
|
|
|
|
The micro-bench/ tests:
|
|
-----------------------
|
|
These should be focused performance tests, ideally testing a
|
|
single metric. Please never forget that these tests are synthetic and if you
|
|
are using them then you understand what metric is being tested. They probably
|
|
don't reflect any real world application loads and the intention is that you
|
|
use these tests once you have already determined the crux of your problem and
|
|
need focused feedback that your changes are indeed improving matters. There is
|
|
no exit status requirements for these tests, but they should give clear
|
|
feedback as to their performance. If the framerate is the feedback metric, then
|
|
the test should forcibly enable FPS debugging.
|
|
|
|
The data/ directory:
|
|
--------------------
|
|
This contains optional data (like images) that can be referenced by a test.
|
|
|
|
|
|
Misc notes:
|
|
-----------
|
|
• All tests should ideally include a detailed description in the source
|
|
explaining exactly what the test is for, how the test was designed to work,
|
|
and possibly a rationale for the approach taken for testing.
|
|
|
|
• When running tests under Valgrind, you should follow the instructions
|
|
available here:
|
|
|
|
http://live.gnome.org/Valgrind
|
|
|
|
and also use the suppression file available inside the data/ directory.
|