Testing like it or not is now mainstream, just about every version of visual studio 2010 has the ability to run native Microsoft unit tests, and there is a plethora of unit testing frameworks out there to choice from for those who don’t like the Microsoft “way”. So there is really no escape, and as we move towards automated rollouts, and a defined build cycle, the requirement to “prove” that the code works has moved from being nice to have being a strict required!
TDD is a technique, which along with traditional design methods and programming patterns, help the developer produce well structured, encapsulated code, which is easy to maintain and extend. TDD on its own will not create great code, but it is the corner stone on which great code is written, One of upshots of working in the TDD way is that the time spend debugging is reduced, after writing code there is no debugging time, which can over a project lifespan save a considerable amount of time, and money.
TDD is based on three simple rules, which lead to the programmer too writing code in a tight loop between the test class and the production code.
Rule 1: You are not allowed to write any production code, unless it is to make a failing test pass.
Rule 2: You are not allowed to write any more of unit test code than is sufficient to fail, and not compiling is failing.
Rule 3: You are not allowed to write any more production code than is sufficient to pass the one failing test
This is not easy (nothing worthwhile ever is!), So like any skill to be effective it must be practiced, and that is what the code kata’s are about, these are simple small programming problems, where the solution is easy to arrive at, but the process of repeating the kata trains the muscles to that you instinctively start coding by writing the test first, and building from there.
Next time some code examples!