• 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?

I managed to get two walls done and everything moved back into place before I left for another business trip. My wife is happy because the bedroom looks better. I did no damage and made noticeable progress. I still have some Painting to do (the capital P is to indicate it will be a Pain). I eventually have to move the bed, rent scaffolding, and so on. That’s probably more in the future than I’d prefer, but I’ll do it when I know I have the time and space to do it.

Contrast this to when we bough the house back in March. I entered an empty house. I managed to get two bedrooms painted (ceilings included) and the “grand” room with 14’ vaulted ceilings. I only nearly killed myself once – don’t lean a ladder against a wall but put the legs on plastic – and it was much easier to move around. I had a clean slate.

Sometimes you’ve got to get done what you can get done to make some progress. When I was younger, my desire to finish the entire bedroom might have stopped me from making any progress. Sure, the bedroom is now half old paint and half new paint, but according to my wife it looks better – and she’s the product owner! I can probably do one more wall without having to do major lifting and when I’m finally ready to rent the scaffolding, I won’t have as much to do. I can break down the bed, rent the scaffolding and then in one day I might be able to finish the remainder of the work. (Well probably 2 days because I’ll end up wanting to apply 2 coats to the ceiling and I’ll need to wait 8 hours).

Painting is just like software development.