I have been looking into Test Driven Development (TDD) for ages now. I have read a number of the books (like Test-Driven Development: By Example by Kent Beck), followed numerous examples, read blogs and newsgroup posts, and started trying it on a couple of personal and small work projects. I can see how powerful it is, and have seen first hand how it can produce a beautiful design, reduce bugs and actually speed development.
Despite this, I am still a completely clueless newbie at TDD. Today I tried writing a small section of a project in TDD, and it ended up fairly useless, so I am writing down my mistakes here so I am hopefully not doomed to repeat them.
- Making the tests too coarse-grained
- Not refactoring early or drastically enough
One of the benefits of TDD is breaking functionality down into small, testable, understandable units. Once you start needing a lot of code to get one test to pass, your test is too coarse. The functionality should be broken up into smaller steps so each step can be tested. “Duh!” you say, and you are absolutely right.
I think both mistakes, made early, conspired against me. Because the tests were too coarse, I had trouble factoring out logical blocks into separate classes without making the tests irrelevant. Because I could not refactor into small blocks, I was unable to make the tests finer grained to test sub-sections of functionality. The TDD process in this case was screaming at me that my design was wrong. Note to self: if this happens again, chuck it out and start again!