blog podcast

TDD or Not?

Not so long ago, a discussion arose at my work regarding test driven development (TDD). If you do TDD, won’t you risk having to cleanup a lot of tests when you start refactoring?

It’s a valid question, when I first started testing out TDD a long time ago I had this issue. I had created a lot of tests, but as I found I needed to do some refactoring, I had a lot of work moving and modifying these tests. These problems don’t happen so much anymore. Actually the discussion at work was a reminder for me of this past and made me wonder why it happened before, and why it’s not happening now.

I think one part of it is regarding how you write tests. If you follow some simple principles like:

I’m a big fan of TDD, even if I don’t always follow it. Once you’ve come over the hurdle of setting up the frameworks of your project and start writing these if-statements that are usually called your business logic it is very satisfying to see the amount of tests grow to cover every path of your execution.

I also think that if you start your projects with TDD, even if it doesn’t feel like you need it in the beginning when your projects are small, you’ll save yourself a lot of pain in the future when the complexity starts growing. If you started with TDD, it’s likely that your code base will be chunked up so that it’s easy to test new functionality. If you did not, well then most likely testing new functionality will be difficult as well.

So to answer the question TDD or not? I’d say definitely TDD.