≡ Menu

Test driven development: is it as fulfilling as non-TDD?

A few years back I was telling one of my former colleagues about a new technique I’d discovered and had been using for a little while: test driven development (TDD). I was full of enthusiasm for this, at the time to me, new technique.

His first question to me surprised me a little: “yes, but is it as fulfilling”?

I was initially unsure how to answer, but said something like yes, that I felt a lot more productive and seemed to spend a lot more time writing code.

After much time spent coding in different TDD environments and after more time to reflect, I can now say for certain that yes, it is more fulfilling.

Let’s consider for a minute to the situation prior to TDD:

    • spending a lot of my time in the debugger, trying to find annoying bugs in other people’s code (or mine)
    • not feeling totally secure in the code base at any point in time, until the QA team had tested it
    • being uncertain about making changes or refactoring, particularly in code that wasn’t written by me, in case I didn’t know what I had inadvertently broken
  • With TDD I enjoy the feeling of being much more confident both in the code I write, and in the code base itself, because it is covered by tests. I like that I can fix bugs or refactor with confidence, knowing that I can run tests to ensure I haven’t broken anything. And that an automated build will also run tests after every check in. And that my team is doing the same.

    I like that I can write a test to reproduce a bug, and then write the production code to fix the bug. And then run all tests to make sure that I haven’t broken anything elsewhere.

    I like that I don’t have to waste as much time stepping through code in the debugger.

    I like that I can go home at night, knowing that all my code has been integrated successfully and that all tests have passed.

    The resulting code base produced is better quality, and bugs can be fixed with more confidence.

    I know that all of the above is only as good as the quality of the tests and of their code coverage. But that’s what being a pragmatic programmer is about; and it’s still a huge leap forwards from the previous situation.

    Feels pretty fulfilling to me!

    { 0 comments… add one }

    Leave a Comment