This blog post regarding test code being harder than application code was passed around the office, and I thought I would preserve my response here. You’ll need to read it first for this to make much sense.

I think there’s a reasonable point that testing is frequently trivialised, but I don’t think saying that the non-testing code is trivial is the right way to get that message across. Discussions regarding what developer testing looks like need to take into account a whole raft of context, which this article doesn’t seem to get into (eg. Defect prevention strategies, architecture, system criticality).

For example, this is completely untrue, unless he is assuming an ideological TDD view of the world:

“The tests are the program. Without the tests, the program does not work.”

Without *testing*, the program probably won’t work. Without tests, the program could easily work perfectly well. You’ll certainly have a program (of possibly unknown quality).

This is sometimes true:

“Sometimes the tests are the hard part, sometimes the code is the hard part.”

…but just as often, the code is the hard part and the tests are easy.

At my last job, I remember a simple code change that took a week of test planning, a custom execution framework, two weeks of execution and another week or so of results analysis (plus DBA support to write performant queries against the data). It would have been nice if his examples had included something along these lines. His search example could have provided an interesting example of this, as well as the limits of automated testing when the results are subjective (ie. ‘Good’ search results).

I’d suggest the main reason tests contain as many errors as code is because both code and test cases are the result of similar communication and modelling processes. The general process of getting working software is the process of bringing the code and the test models into alignment.

Where tests have *more* bugs than code, I’d suggest it’s usually a result of the test design time being squeezed, and the fact that nobody really likes writing procedural test cases.

Jared