Adding new tests to glean

On this page, we'll consider some general testing principles and suggest areas in which new tests are needed. When you're ready to implement a new test, check out the overview of glean internals.

Guidelines for writing glean tests

To define a new test, first create a new test class derived from Test. Most of the time you'll want to write tests that run on all drawing surface configurations and are portable (in the sense that they don't use any OS- or window-system-dependent data structures exposed in the Environment, WindowSystem, and DrawingSurface classes). Starting from BasicTest may be easiest in those cases.

Once you've created a new test class, create one or more global objects of that class. The constructor for Test ensures that all such objects are automatically linked onto the master list of tests. (Creating test objects dynamically isn't recommended, but if you can make a good argument for it we can figure out the rules needed to make it work.) Every test must have a good description; it's very much worthwhile to add text that will help the user understand the results or debug the problem if something goes wrong.

The first workhorse method in any test class is run(). Here are some things to remember about it:

The second major method is compare(). Some things to keep in mind:

It's important to make sure that all OpenGL state variables are set in the way you expect; otherwise a drawing operation can have surprising results. This OpenGL Rendering and State Cheat-Sheet can help you determine what state variables you need to set (and might suggest a few things that need testing, too).

New tests

Here are some suggestions for categories of tests that could be added to glean. (These are not listed in any particular order; any of them would be worthwhile.)

In addition, please see the JOBS file in the top level of the glean source tree for an informal list of specific requests.