Chromium Test Plan
This page describes the Chromium test plan.
The test plan should be executed prior to releasing new versions of Chromium.
The goal is to ensure that each release of Chromium meets a certain
minimal level of quality.
- Compilation tests - test compiling Chromium in the following ways:
- Linux debug build
- Linux release (optimized) build - if possible, test with a variety
of gcc versions and different distros.
- Linux threadsafe release build
- Linux DMX release build
- Windows release build
- Other Unix release build
The tests below should be done with a release build.
- Basic SPU tests
- crdemo.conf - tests Pack SPU
- simplemural.conf - tests Tilesort SPU
- reassemble.conf - tests Tilesort SPU with rendering into the
original application window. Be sure to test resizing the window
to exercise the dynamic tile configuration feature.
- psubmit_first.conf - tests Tilesort SPU with a parallel
- psubmit_last.conf - tests Readback SPU
- psubmit_bswap.conf - test Binary Swap SPU
- local.conf - tests Hidden Line SPU and OpenGL command filtering
with just an application node.
- cavetest1.conf - tests non-planar tilesort for virtual
reality systems, like the CAVE.
Four rendering servers will show north, south, east and west views
of the city demo.
Use x/X, y/Y, z/Z to simulate moving the observer's viewpoint in the
- cavetest2.conf - like cavetest1.conf but divides each "wall"
into two tiles.
- multitilesort.conf - tests a two-tiered tilesort configuration.
The scene is rendered both into the original application window and
to a two-tiled mural.
Test resizing the application window.
- packertest.conf - tests the packer/unpacker for completeness.
Generates calls with permuted arguments for all specified enums and args.
- Thread safety tests
- Build Chromium with thread safety enabled
- threadtest.conf - note that there are four different modes which
can be chosen from in this configuration file
- The glthreads.c demo from Mesa can also be tested. Use the -n
option to specify the number of threads and windows to create.
- Stereo rendering tests
- stereo1.conf - tests that a quad-buffered OpenGL app works in
passive stereo mode.
Also test with the -force option to test that a non-stereo app can
be coerced into passive stereo mode.
- stereo2.conf - tests that a non-stereo OpenGL app can be coerced
into rendering in stereo mode. Default stereo mode is SideBySide.
Specify -mode CrystalEyes to test active stereo if your graphics
card is capable of that.
- stereo3.conf - tests combining non-planar tilesort with stereo.
Three windows will appear, each showing a SideBySide stereo pair.
Defocus your eyes to see the stereo effect.
- stereo4.conf - like stereo3.conf but requires a stereo-capable
graphics card to test active (quad-buffered) stereo mode.
- CRUT tests
There are three CRUT test configurations.
In all cases, first make sure you delete the lib/Linux/libGL.so*
symlinks if they exist.
- crut_fan.conf - Note: you must start the app/server processes
in this order: crappfaker, crappfaker, crutserver, crserver.
Use the left/right mouse buttons in the "CRUTServer Interactive Window"
to enlarge/shrink the rings
- crut_ring.conf - start the app/server processes in this
order: crappfaker, crappfaker, crutserver, crserver.
- DMX tests
- First, you should have DMX up and running on your display wall.
- Second, edit mothership/configs/dmx.conf, specifying the correct
values for TILE_COLS, TILE_ROWS and HOSTS.
- Third, try running the atlantis demo on the DMX/Chromium display:
python dmx.conf atlantis
You'll be prompted to start crservers on each of the back-end
- Finally, test the auto-DMX feature.
See the DMX section for details.
- Graphical Configuration Tool
- Make sure mothership/tools/configtool.py runs.
You may have to install some WxWindows packages first.
- Test the tilesort, reassembly and sort-last templates.
- Save a few configurations and make sure they work properly.
- Try reading an arbitrary config file into the config tool to be
sure its parser works.
- Application Testing
The following applications are frequently used with Chromium:
The following Mesa programs are good tests:
- tests/bufferobj.c - tests GL_ARB_vertex_buffer_object
- tests/getprocaddress.c - test glXGetProcAddress
- tests/vparray.c - tests vertex programs with vertex arrays
- tests/texrect.c - tests GL_NV_texture_rectangle
- demos/cubemap.c - tests cube texture maps
- demos/fplight.c - tests NVIDIA vertex/fragment program extensions
- demos/*.c - tests all kinds of OpenGL features
Other good tests:
- Chromium's arbfraglight.c - tests GL_ARB_vertex/fragment_program
- Chromium's viewports.c - tests that glViewport works correctly
- Cg demos
- Performance Tests
- The framerates of programs like city.c and atlantis.c should be
recorded by the developer for comparison purposes.
Occasionally check performance to be sure there's no degradation.
- The new spheres.c demo can be used to measure triangle throughput
in sort-first and sort-last configurations with immediate mode
vertex arrays, display lists and vertex buffer objects.
- Mothership auto-start mode.
- Feedback SPU for OpenGL feedback/selection support.
- mothership/daughtership process spawning