When you start out with OO, it’s not that easy to recognize some pitfalls… people start using GOF patterns even when they aren’t necessary, they start creating complex inheritance hierarchies, etc… It’s kinda similar to the path you go through when you start out with TDD… a lot of people start out enthusiastically there as well, until they get bitten by the fact that some of their tests are testing too much, or they are testing at a level that is too high.

In both cases, you only make a ‘leap’ up the skills-ladder once you start recognizing the fact that simplicity is the really the key to doing anything effectively. Trying to keep everything simple, and isolating the hard parts are two principles that (i think) kinda form both your OO skills and your TDD proficiency. When a developer is exposed to easy but effective tests, that developer will pick up some good OO design tips from that. And the other way around works as well: whenever you learn a new good OO design tip, you might use it to make some of your tests simpler… so to make a long story short, i think they somewhat go hand in hand.

I think I’m at early stage 3. My main problem with TDD is in resisting upfront (subconscious) design, which tends to result in over-specified tests and a convoluted design (longish strings of classes).

I tend to fall into the trap of writing tests assuming I’ll need something, rather than waiting until the test “naturally” demands it (or writing the test as a self-fulfilling prophecy to get what I think I’ll need). I guess this is just a bad habit I have to break. Also wouldn’t hurt if my OO design skills were better.

Which brings me to another question I’ve been thinking about for a while. Do you think TDD is an effective way to learn good OO design (design patterns, SOLID principles etc), or are good OO design skills a prerequisite for doing TDD?