JEFF:What is a test suite?
ERIC:A test suite, to my mind, is a way for people to measure
implementations against a "fixed" reference point. I put quotation marks
around fixed because any good test suite will evolve over time, adding new
tests as people propose them and refining the tests that already exist - so
the suite isn't really fixed, in the sense of never changing. It is, or
should be, a fixed point in the sense that a good test suite is
implementation neutral and does a good job of allowing implementors to use
it as a major tool in testing their work.
JEFF: And a test suite is different from a validator?
ERIC: Yes. A test suite - in this case, a series of Web pages - contains
tests for all of the features of whatever it is you're testing; in this
case, we have a test for each value of the properties of CSS1. This
lets users take their favorite browser and run it through the suite,
checking the browser's display against the ideal behaviors described in each
test.
A validator, on the other hand, is a tool with which a user can check his
or her stylesheets for correctness. This helps designers verify that
they're using the right syntax in their stylesheets and that any problems
in the page display aren't due to incorrectly written styles.
Put another way, a test suite is kind of like a book of ideal phrases and
sentences, whereas a validator is more like an editorial proofreader.
JEFF: So explain your test suite.
ERIC: "My" test suite, the CSS1 Test Suite, is really the work of three people,
with input from several others. The main three are me, Hakon Lie (co-author
of the specification), and Tim Boland of NIST, who did a mind-boggling
amount of work in ferreting out 500 test-table statements in CSS1. I
served as project coordinator, basically, taking work Hakon and Tim had done
and grafting it onto some pre-existing work of my own. The final result was
announced in conjunction with the recommendation of CSS2 by the W3C.
The CSS1 Test Suite tries to be all the things I described earlier by
providing test statements in which we not only provide CSS1 rules to see if
the browsers get them right, but each statement describes its optimal
rendering. So, to take an obvious example, when testing for color, we define
a rule like <CODE>.one {color: green;}</CODE> and then have a
paragraph with class one, whose text is, "This paragraph should be green." If
the effect you see doesn't match the text, then you know something went
wrong. Of course, finding out what went wrong can be half the fun.
next page»
