Re: compiler/translator testing techniques

> > For a link to compiler performance testing, see http://www.nullstone.com
> > [If you're serious about testing, it's a lot cheaper to buy a serious
> > test suite from a company like Nullstone than to try to concoct your
> > own. -John]
>
> Thank you for link, I'll investigate it.
>
> The question concerned not really performance (but it also very
> important) but approaches to verify ready compiler created with
> lex/yacc pair or fully custom how it conform to customer's
> requirements. Really technique to create testing environments,
> testcases, what should be tested first etc.
>
> I think this question to people with some experience in creating
> _industrial_ translators/compilers.


The various techniques I have seen are:


1. Sutes, collected statements designed to test all reasonable
constructs and corner cases.


2. Simply running on many large programs known to be correct.


3. Test cases that are automatically generated by program (like a
program with impossibly deep nested calls, etc).


4. Fault injection, example, taking an existing large program and
taking out each sucessive tolken in the program and compiling it, or
adding a noise tolken between each tolken, then logging the number of
errors resulting. This finds error cases that cause error recovery to
collapse.


THats the ones I know. Observation, most testing is fairly ad-hoc.


PJ Brown from a long time ago, avocates feeding the compiler the wrong
language (!) to see if it recovers.

Return to the comp.compilers page.
Search the comp.compilers archives again.