TDD is how I do it, not what I do

Brett Schuchert — Mon, 21 Jul 2008 14:32:00 +0000

“Do not seek to follow in the footsteps of the men of old; seek what they sought.” ~Basho

That quote resonates with me. I happend across that a few days after co-teaching an “advanced TDD” course with Uncle Bob. One of the recurring themes during the week was that TDD is a “how” not a “what”. It’s important to remember that TDD is not the goal, the results of successfully applying TDD are.

What are those results?

You could end up writing less code to accomplish the same thing
You might write better code that is less-coupled and more maleable
The code tends to be testable because, well, it IS tested
The coverage of your tests will be such that making significant changes will not be too risky
The number of defects should be quite low
The tests serve as excellent exampls of how to use the various classes in your solution
Less “just in case” code written, which typically doesn’t work in those cases that they targeted

Right now I do not know of a better way to accomplish all of these results more effectively than practicing TDD. Even so, this does not elevate TDD from a “how” to a “what.” TDD remains a technique to accomplish thigns I value. It is not a self-justifying practice. If someone asks me “why do we do it this way”, saying something like “we practice TDD” or “well you don’t understand TDD” is not a good answer.

We had an interesting result during that class. One group was practicing Bob’s three rules of TDD (paraphrased);

Write no production code without failing tests
Write only enough test code so that it fails (not compiling is failing)
Write only enough production code to get your tests to pass.

But they ended up with a bit of a mess. Following the three rules wasn’t enough. These rules are guiding principles, but those three rules mean nothing if you forget about clean code, refactoring and basic design principles (here are a few):

S.O.L.I.D.
F.I.R.S.T.
Separation of Concerns (Square Law of Computation)
Coupling/Cohesion
Protected Variation
...

TDD is a means to an end but it is the end we care about. What is that end? Software that has few defects and is easy to change. Tests give us that. Not testing generally does not give us that. And testing in a common “QA over the wall” configuration typically does not cut it.

Since I do not know how to so easily produce those results in any other way. TDD becomes the defacto means of implementation for me. That doesn’t mean I should turn a blind eye to new ways of doing things. In lieu of any such information, however, I’ll pick TDD as a starting point. This is still a “how” and not a “what”.

It turns out that for me there are several tangible benefits I’ve personally experienced from practicing TDD:

Increased confidence in the code I produce (even more than when I was simply test infected)
Less worrying about one-off conditions and edge cases. I’ll get to them and as I think about then, they become tests
Fun

Fun?

Yes I wrote fun. There are several aspects of this:

I seem to produce demonstrable benefits sooner
I actually do more analysis throughout
I get to do more OO programming

Demonstrable Benefits Sooner

Since I focus on one test at a time, I frequently get back to running tests. I’m able to see results sooner. Sure, those results are sometimes disjoint and piecemeal, but over time they organically grow into something useful. I really enjoy teaching a class and moving from a trivial test to a suite a tests that together have caused what students can see is a tangible implementation of something complex.

More Analysis

Analysis means to break into constituent parts. When I practice TDD, I think about some end (say a user story or a scenario) then I think about a small part of that overall work and tackle it. In the act of getting to a test, I’m doing enough analysis to figure out at least some of the parts of what I’m trying to do. I’m breaking my goal into a parts, that’s a pretty good demonstration of analysis.

More OO

I like polymorphism. I like lots of shallow, but broad hierarchies. I prefer delegation to inheritance. But often, the things I’m writing don’t need a lot of this – or so it might seem.

When I try to create a good unit test, much of what I’m doing is trying to figure out how the effect I’m shooting for can be isolated to make the test fast, independent, reliable … To do so, I make heavy use of test doubles. Sometimes I hand-roll them, sometimes I use mocking libraries. I’ve event used AOP frameworks, but not nearly as extensively.

Doing all of this allows me to use polymorphism more often. And that’s fun.

Conclusion

Am I wasting time writing all of these tests? Is my enjoyment of my work an indication that I might be wasting the time of my product owner?

Those are good questions. And these are things you might want to ask yourself.

Personally, I’m pretty sure I’m not wasting anyone’s time for several reasons:

The product owner is keeping me focused on things that add value
Short iterations keep me reigned in
I’m only doing as much as necessary to get the stories for an iteration implemented
The tests I’m writing stay passing, run quickly and over time remain (become) maintainable

Even so, since TDD is a how and not a what, I still need to keep asking myself if the work I’m doing is moving us towards a working solution that will be maintainable during its lifetime.

I think it is. What about you?

Object Mentor Blog: Tag what

TDD is how I do it, not what I do

Demonstrable Benefits Sooner

More Analysis

More OO

Conclusion