Commit early and often…to TDD


So you’ve read my blogs Why TDD and 5 Steps to Good TDD and you think, that’s great, makes a lot of sense.

Then it comes time to write the code and you have a tight deadline and testing just goes by the wayside. Sound familiar?

So here are some good ways to motivate yourself and your team to actually practise TDD.

1. Have a test coverage race!
Simplecov will record your unit test coverage for Ruby and I’m sure other frameworks have similar coverage units. Figure out an appropriate prize (honor? a pint? ice cream?) and give it to the person or team with the highest test coverage. Or if you’re on your own, you choose the prize!

2. Understand that TDD is a form of delayed gratification
You’re balancing the immediate reward of having a feature to show off against the later and bigger reward of having a debuggable and extensible feature. It’s in our nature to want immediate gratification but building the discipline to delay it means you’ll end up with better features. Delayed gratification is a useful skill in many areas of life, so you definitely won’t lose anything by strengthening that skill while programming.

3. Spend a week rigorously TDDing and find out if your code is actually better
We humans aren’t always great at accurately judging how we spend our time. TDD may seem slow, but why not actually measure your progress with it? Some ideas of things to track: how many bugs are deployed, average time spend solving each bug, how easily you can make changes and catch bugs.

4. Read research on TDD efficiency
A quick Google search led me to quite a lot of papers on the efficiency of TDD. It’s midnight, and I have only glanced at a few, but it’s probably better to read those than spend a week tracking your own code (although sometimes the hands-on approach is best). In particular:

“This study finds that Test-Driven Development provides a substantial improvement in code quality in the categories of cohesion, coupling, and code complexity.” –Rod Hilton

“We observed a significant increase in quality of the code (greater than two times) for projects developed using TDD compared to similar projects developed in the same organization in a non-TDD fashion.” -T. Bhat

Is there hard evidence of the ROI of unit testing? A very interesting Stack Overflow thread.

5. Sing the Ballad of RSpec
Testing is definitely an epic adventure, so you need questing music to go along with it. I’ve written this ballad — apologies to those who test in other languages but I’m sure you’ll still enjoy it. I’ll record it at some point, and then you can really get into the testing groove.

Read my other posts:
5 Steps to Good TDD

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s