CSE 131A, Winter 2007: Testing

Some of you may be wondering about testing your code, and so we'd like to share some of our accumulated experience in this very important activity. Today, we'll talk about how to the art of writing test cases. This skill will serve you well in future assignments, as well as any future programming that you do.

In order to test out your own implementation, be sure to design test cases that cover all possible lexical rules as defined in the spec.

The first fundamental principle of testing is to make sure that every line of code is exercised. To do this, you should first make sure that you test for every keyword and punctuation mark listed in the tables.

Next, look at each rule one by one, building up your test cases from simple examples, and thereby assure yourself that the a larger test parsed correctly. For Example, QName is defined as follows:

QName ::= ( Letter | "_" ) ( Letter |  Digit | "." | "-" | "_" )*

It follows that you must test out each alternative within each parenthesized subexpression of QName

Thus, there are 2 alternatives in

( Letter | "_" )

and 6 alternatives in

( Letter |  Digit | "." | "-" | "_" )*

(There are 5 possible tokens as well as the empty string)

Now, you ask if one should test for many "repetitions" of Kleene closure What do you think?

You may use the lexical spec as a guide to help organize your testing.

The second principle if testing is that all possible paths, through the code must be executed. You won't likely be able to test all such paths--there are too many of them-- but you can still test a meaningful number of paths of some designated length.

This systematic approach will go a long way to covering many test cases.