One of the books that I am reading at the moment is “First Things First”, it mentions a cultural difference (yes blatant generalisation) between east and west along the lines of:

• West – if it ain’t broke, don’t fix it
• East – kaizen (continuous improvement).

This idea probably encapsulates the biggest change unit tests have made to my approach. I will now design and code with confidence that I can improve the code at any time.

That idea allows me to start without (too much) future thought as to what will be required – great for someone who makes use of intuition to program. I have often spent considerable non-programming time proving to myself and others that an idea will work. What does having a unit test have to do with this? It provides a framework where change is expected – sometimes an intuitive idea just does not work. I can rely on tests to prove the idea, or not. A schedule of work can be broken into smaller pieces, each of which I can focus on individually. The individual focus effect provides a productivity gain. Instead of building the mental castle of an entire source code structure, I can concentrate on the unit in front of me. (If there is a side effect because of what I do, it will be reported when the tests are run – note that I include integration testing in my idea of a ‘unit’ test framework.) Though I was always willing to make cosmetic code improvements to something that I had personally written, I would regularly reach a point where I would be hesitant. Now, things like cosmetic changes to provide better code understanding, and design changes to better suit the application are done (almost) without hesitation. It is possible to ensure that the code still works even when I make major structural changes.

The cost in using a unit test framework is of course in writing and maintaining the tests. However, the way I have always worked, is code a bit, test a bit, code a bit more, test a bit more, etc. So there has always been a testing cost in what I write, it is just that now the test has also become a deliverable. There could probably be a debate on which approach costs more – possibly over a project lifetime they may be the same? Plus I like the idea that I can code a bit, test that bit, code a bit more, test it all, code a bit more, test it all, etc.

by