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 application
  • 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 cave.
  • 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_proxy.conf
  • 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 display hosts.
  • 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:

  • VisIt
  • Paraview
  • MeshTV
  • OpenRM
  • Quake

  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 extensions.
  • Chromium's viewports.c - tests that glViewport works correctly with tilesort.
  • Celestia, FlightGear, Glean, Performer
  • 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.

• Miscellaneous
  • Mothership auto-start mode.
  • Feedback SPU for OpenGL feedback/selection support.
  • mothership/daughtership process spawning