Test-driven development is not really as easy as they say. Maybe nobody said it was easy, but I got that impression.
I’ve been trying to do TDD for about two years, and at first I thought it was horrible. Mostly because it forced me to break dependencies to the degree that my code was no longer nice and self-contained the way I used to like it.
Then I fell in love, or became infected, whichever you prefer. I realised that the dependency-breaking is a good thing, and that it’s pretty incredible to have automated regression tests for all your code. I tried to test-drive everything, and valued testing in isolation higher than anything else.
Now I have come to the conclusion that I’m not very good at testing behavior. I tend to test every possible detail, control flow or error condition I can come up with, and this causes the tests to lock the code beyond modification.
I’m trying to find a middle ground where I lock down interesting behavior and choose units at the right level of detail to begin test-driving. Maybe then I can get the extra boon of having the tests tell me more about what I need to build, rather than just making it more difficult to change existing code.
I think it comes down to experience in OO design. I doubt a beginner using TDD will automatically produce better designs than a more experienced developer who is not test-driving.
This just goes to show what I’ve suspected for a while: agile practices are generally very well distilled best practices, but they do require significant prior experience on behalf of their users to be beneficial.
Or maybe I’m just a slow learner.