Test the Goal of the Code

It is time to get technical again. We have been writing unit tests for some time. We have tried test-driven development. However we have never been disciplined in this. Sometimes we don't write tests at all. Sometimes we don't fix the test suite when code is needed to change. Sometimes we just decide that well, this project or that part of the project does not need tests (typically when it seems to get complex or difficult to test!). We have come to a conclusion that with this approach we will never totally master the skill, and not get the benefit it is supposed to bring.

We decided to try another approach. We are writing a very real hard-time constrained, very hardware related code with 100% test-driven development (TDD) in C. A code exists to do the job, but we are gonna completely re-write it. It is originally ported to C from assembly, and this is done maybe four years ago. Since then it has been improved, modified, and adapted to new situations. What has happened is the code has rotten, it is a jungle of conditional compilation, and so forth. So what is better place to do a tiny bit of always refreshing skunk work and completely re-write the whole piece of art?

Right after we made the decision that we are gonna write EVERYTHING with test-driven development we noticed a change in thinking. We constantly think for the simplest possible thing to do, constantly re-evaluate the module (C file) interfaces and so on. If you are gonna do everything in this manner, there just is no backdoor for you.

Another big change was (well, we still need constantly remind ourselves about this) the shift in thinking towards writing the tests as specification. We often ended up thinking about the solution and then writing tests to check the solution. This is maybe caused by the fact that one shot on the code exists and is thoroughly known. However, you will create novel, simple solutions for your tests only if you think about what you want your next small code-to-be do, not how it will do it. Keith Ray has listed questions to help you in this.

Sean Shubin has done a nice work and listed first guidelines to TDD. Again:

Test the goal of the code, not the implementation