TDD has hit the mainstream and every man and his blog has some sort of article about it and how it should be done.
Sadly, it’s somewhat like teenage sex, everybody is talking about it, most are not doing it and those that are doing it, are doing it wrong.
Firstly, there is the big mistake that TDD has something to do with testing. Here’s the big clue for all you programmers out there. It’s not. It’s a different (some may say incremental) design technique that practised properly ends up with designs that conform to many of the principles that Bob “UncleBob” Martin has been talking about for ages. For some really interesting insights into building large and complex systems using OO techniques have a look at these:
- Dependency Inversion Principle
- Granularity — Packaging Principles
- Interface Segregation Principle
- Liskov Substitution Principle
- Open Closed Principle
- Stability — Package Dependecy Principles
These topics are also covered in Bob’s book, Agile Software Development: Principles, Patterns, and Practices in much greater detail. Don’t be fooled by the title, it does cover a bunch of the Agile practices, but it really is about building OO systems in a professional way. It is very, very good.
Now, onto my next missive, TDD is hard, but it’s hard in a good way, not hard in a bad way. Hard in the feeling of satisfaction that you get after exercising. And in many ways, that’s what it’s all about, keeping your code in good shape. There has been a thread started with this message in the Extreme Programming mailing list that really highlights doing it wrong. The best news here is that if TDD starts to feel hard in a bad way (seems messy and untidy) then you’re doing it wrong.
TDD practised correctly does produce good flow, and things come together cleanly. A part of TDD is the concept that the test code is a first class user of your production code. Purely by having “2 masters” during development goes a long way to conforming to many of the principles mentioned above. However, to prevent a number of the issues found in the TDD doubts thread above it’s almost a certainty that much of the testing code will rely on using mock implementations. However this can also go wrong.
For a bit more on the philosophy difference of mock and Mock, Marty does a great job of clarifying the difference here.
Finally, if you’re interested in learning more, read the book by Kent Beck, Test Driven Development: By Example and if you’re a Java developer JUnit in Action is also excellent.