Don’t Test Generated Code

Note that generated code also falls into this category. The benefits of generating source code have proven themselves for decades. Early compilers were assembly code generators. Many compilers are generated from descriptions of their lexemes and grammars. XML parsers, regular expression generators, and CORBA, SOAP, and REST interfaces all use code generation in many implementations. Trends toward domain-specific languages (DSLs) and higher-level constructs frequently employ generators, at least in their early incarnations. So why wouldn’t we test that code?

First of all, code generation usually derives from a solid theoretical or experiential foundation. The generators implement empirically or algorithmically correct approaches to solve the problem. While this does not guarantee a correct implementation, it provides a solid basis for more proven solutions.

Second, generated code often solves problems for which the authors or the industry have not come up with generalized implementations. This means that the generated code is usually repetitious and is thus tedious to test.

Finally, I have found that much generated code ignores many good design principles, making it difficult to test. Many of the theory-based generators come from procedural heritages and do not share the same level of obsession with small functions that we see in current programming paradigms. And the code is simply not designed for human maintenance.

Test that you have used the generator to correctly achieve the purpose for your system. If you are using a compiler generator, make sure the generated compiler accepts the language you are trying to implement. For a remote API, test the business purpose of the API via the generated stubs.