October 18, 2007
@ 02:02 PM
Comments [2]
TDD tidbit - Who tests the tests?
One question I don't hear asked too much is "who tests the tests?" - after all we are writing all this additional code - if we write so many bugs in our production code that we need tests - what are the chances the test code is clean?

The current answer I have is that the code, the tests and the acceptance tests all test each other so if one fails we'll spot the problem in at least one of the others. I hope that this  it is a good enough answer... :)

What do you think?


 
Tags: Everything | TDD

« Who needs an architect anyway? Part I | Home | Functional programming - F# and Erlang »
Thursday, October 18, 2007 8:27:14 PM (GMT Standard Time, UTC+00:00)
For 90% of my test functions, they are simple enough to be self evident. If I get a failure, the first thing I do is reivew the test for errors and get more eyes onto the test to ensure that they are doing what they are supposed to be doing.

In the event that the test contains a complex construct, I do place 'Tests for the test' that are themselves simple enough to be self-evident in their correctness.

I then immediately set about to change the design in such a way that the complex testing structure is no longer required.
Steven Mitcham
Thursday, October 18, 2007 10:36:38 PM (GMT Standard Time, UTC+00:00)
Hi Steven,
Thanks for the comment

Making sure the test works (as in runs) is the simple part - making sure it tests the what's needed is the more tricky part. After all both the test and the code are written by the same person. That's what makes the acceptance tests so important, they are written by someone else so you get a "second opinion" on what you are doing.

Arnon
Arnon Rotem-Gal-Oz
Comments are closed.