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


In the first of three blog posts about TDD, I discussed why TDD is important.

In this post, I’ll highlight five behaviours that will make your TDD much more effective.

1. Write the test first
Obvious? Yes. Easy? No. But it’s really important to make sure your test can fail (is red) — if it can’t fail, then there’s no point in writing it, because it’s vacuous (won’t tell you anything). Don’t you dare write a single line of code before having a failing test!

2. Solve one error at a time
It’s tempting to jump ahead when you know what the next two steps should be. But get in the habit of being rigorously methodical about your test-solving. If you have a no-method error, define the method but don’t let it do anything. Let the error messages guide you.

Again — obvious but difficult to do.

3. Run your tests before committing to GitHub
You never know what fun thing has broken and it’s awfully embarrassing to push code up with failing tests.

4. Run your tests after pulling from GitHub
In case your colleague or you in a previous life has forgotten step 3.

5. Don’t refactor until you have a green test.
This is a hard discipline, but it will save you hours. Trust me. I spent a couple hours in a red/refactor/red/red/red/red/red/red/red/red/red. Total waste of time. Never again.

Read my other blog posts in this series:
Committing to TDD