|compiler testing email@example.com (1987-08-28)|
|compiler testing harvard!rutgers!eddie.mit.edu!culdev1!drw (1987-09-18)|
|Date:||18 Sep 87 16:39:14 GMT|
|Organization:||Cullinet Software, Westwood, MA, USA|
firstname.lastname@example.org (Frank Wang) writes:
> We are designing a special purpose compiler for a new product. It seems
> not very difficult to make it work. But testing is a problem to us now.
> How can I make sure that no invalid syntax or other errors are not validated
> by this compiler? Are there any books or articles about this?
Build a solid library of test cases of both valid and invalid code.
Save the listings, and have some system for automatically running all
the tests and comparing them with the listings.
Design the tests to exercise everything thoroughly. If you notice
some 'tricky case' while writing the compiler, put in tests to
exercise it. For *every* bug the compiler ever has, put in a test
case to exercise it, because old bugs are likely to show up again.
It helps to add some switches to the compiler to make it print out
various 'internal' things in the listings. Especially useful is
generated code and symbol table information. This way you can check
that things are really being done right inside, rather than having to
check the indirect consequences of internal operations.
We did this here at Cullinet, and it really gets the bugs out.
Return to the
Search the comp.compilers archives again.