Limits of TDD

Last week I’ve been participating in the challenge. It’s my first attempt, and being a TDD-addict, of course I tried to build the game using Test Driven Development.

Apart from being on a tight schedule, something I beforehand imagined would make it hard for me to finish the “assignment” on time, I have come up with another, more speculative excuse for myself.

That is the excuse of the Limits of TDD.

I find it hard to acknowledge that there are limits to TDD’ing, since I’m such a sucker for the method. I love TDD’ing, when in the “flow”, as Corey Haines put it. I’ve done it for three or four years, first spare time, then more and more at work too.

I believe Michael Feathers once said that to him TDD’ing all boils down to one simple lesson: separating the how from the what. That is, focusing on the logical behaviour of your system (semantics), instead of the physical form of it (syntax).

I think one problem I had during the week was that I didn’t know what I wanted. When the what isn’t for sure, or unclear, TDD becomes very hard. That’s why problems solved during katas/coding dojos/code retreats (“a dear child has many names” as the Swedish saying goes) are so clearly expressed and well known.

So what I’ve done during spare time, is solving Roy Osherovs String Calculator kata. At least I TDD’ed. 🙂 I just didn’t end up with a game.

Trying to learn from this experience, here are some improvement ideas:

  1. Draw sketches of the game, deciding how it will behave. That is, ignore the nagging “how do I know if this is fun or not?”-feeling. Fun is not mechanically testable, and should be left for manual testing.
  2. Develop together with someone else, deciding and discussing how the game should work. I was alone on this one. That way I get more traditional producer-consumer (or client-consultant) dynamics, instead of being both the customer and the developer myself.
  3. Build the game without TDD, but resort to TDD for the Lego-pieces found during development. One such Lego piece I thought about was spring physics to simulate the game. That is really good material for TDD’ing, since I know the details on that kind of behaviour.

(3) breaks the top-down (or end-to-end) notion I’ve come to love about TDD. But how can top-down work if I don’t know what the behaviour of the “whole game” is?

In conclusion, I find TDD hard to apply to “experimental” software, software where the behaviour is not even known. It’s easier to TDD mathematics and physics.

Without the *what* (input-output), the *how* (internals) is impossible to get right


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s