TDD Accelerates Development

Periodically, well-meaning Agile advocates will make the argument that practicing Test-Driven Development trades development speed for better quality. That is, it slows you down but it’s worth it because the resulting code is better.

Rubbish, I say. TDD makes me a faster coder.

I could make a number of arguments here about TDD speeding up development in the long-term – TDD cuts down on time spent chasing regression bugs; TDD helps avoid writing code you don’t actually need; etc. And they would all be true and valid arguments.

But I think I can make a case for TDD accelerating development in the short-term as well.

When I started out programming, starting a new project or a new feature was a haphazard process. I’d often start off with “Blank Slate Syndrome” – not knowing where to begin, I’d freeze up for a while considering different angles to attack the problem from. Then I’d make a few tentative stabs at different parts of the program. Often beginning to write one subsystem would lead me to think of something else I’d be “needing”, causing me to leave the current piece half-finished and work on something else. After a few days of chasing these tangents I’d have a bunch of false starts, rewrites, and half-written methods lying around, and no working code.

Learning to practice TDD drastically cut down on my blank-slate issues, because now the question “what next” always had a simple answer: make a failing test pass. If all the tests pass, write a new test. Don’t worry about what you will “need”; just make those tests pass. This alone gave me a huge boost to my initial ramp-up speed in new projects.

Of course, this still left me with the question: what test do I write next? Lately I’ve found that using Cucumber to write acceptance criteria for my apps has all but eliminated this last vestige of Blank Slate Syndrome. When I’m just getting started and I’m not sure where to start writing tests, I step back and write a plain-english explanation of the functionality I want to implement. Then I start at the beginning and start turning each step into runnable code with Cucumber. If at any point I find myself writing non-trivial amounts of code in order to make the step pass, I drop down to the unit level and start writing RSpec expectations (unit tests). Then I move on to the next step, and so on.

The upshot of all this is that I find myself wasting very little time on premature architecture and false starts at the beginning of a project r a feature. And that means real, short-term savings of time.

This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.
  • bryanl

    here here!

    • avdi

      Would you say that testing all the fuckin' time accelerates your development to ludicrous speed?

      • bryanl

        not quite. maybe to plaid. but there is an increase.

  • greymaiden

    Am I too oldschool if I say I conquer blank slate syndrome by making a flowchart before I start programming anything?

    I gotta admit, I never bother writing tests, but I've never worked on any large app so it probably doesn't matter.

    • avdi

      These days we call that sort of thing Big Design Up Front, and yes, it's very old-skool ;-)

  • Kevin

    Good Article!
    I like the last part about starting with the acceptance test (in Cucumber) and maybe *that* can be your failing test until it proves that you go past a certain threshold and need to drop down to unit tests.
    Maybe that approach will lead to code that is well-tested in a black-box manner as much as possible.

    • avdi

      Thanks, Kevin! I'm liking the Cucumber approach more and more lately – I recently used it to spec a command-line executable by having the Cucumber specs actually start the executable as a separate process and validate the output.

  • ywam

    TDD – Interesting to read one , keep up the good work posting : )

  • sicily villa

    practicing Test-Driven Development trades development has many advantages in the long term.using Cucumber approach to write acceptance criteria for apps has all but eliminated this last vestige of Blank Slate Syndrome.In cucumber start at the beginning and start turning each step into runnable code.