So You Want to Try Test-Driven Development

Five years ago I started to use test-driven development (TDD). No other practice has catapulted my technical ability more. As an aside I have learned to do TDD three times now.

If you want this article to sell you on TDD, stop reading. If you want to try TDD, this is your article.

Step 1: Forget Everything
There is a lot of talk about TDD in the world. Forget that noise. Go into this exercise with an open mind. You may find that TDD is worth more of your time and effort. You may not. Get yourself to the point where you can try this without having already made up your mind.

Step 2: Pick A Problem
Every developer should have a few problems they use to learn new technology. It provides a baseline and a common thread to learn through. If you have one, use that one. If you don't, read 2a.

Step 2a: The Vending Machine
Build a vending machine. The vending machine accepts coins and allows you to make a selection from its inventory. The vending machine will dispense the item you have selected if you gave it enough money. If you don't have enough money, it will give you your money back.

Step 3: Tooling
Pick whatever you want. The criteria are that whatever you choose, have the tools or ability to build and run a suite of unit tests.

Step 4: Rules
Now its time to begin. Here are the rules for how you'll build out your sample problem or the vending machine I provided. Keep this exercise to within 30-45 minutes.

1. All code you write is in the form of a test
2. Write all code within one source file
3. Each test must fail at least 1 time
4. You may only move or extract code from your tests after they have passed

Those are the four rules. The first rule means you will not write implementation code outside of your test. You must write the implementation within the test itself. Second, no test file and source file separation. Keep them together. Third, every test you write needs to fail the first time to protect the Red, Green, Refactor loop. So write a failing test! Last, after you have fixed a broken test you may move your implementation out of the test, but within the file.

These rules force you to follow the Red, Green, Refactor loop that is essential to TDD. These rules seem obnoxious to everyone, but remember step one? Try this out, even if it seems stupid.

Closing
So it has been 45 minutes of following a few strict rules that force you to solve a well-known problem with your tests. Think about how you'd answer these questions:

• Did you start by writing a failing test?
• What was it like trying to choose which test to write?
• Did you find yourself wanting to skip some of this test stuff and go right to the implementation?
• Did you write a test that you thought was pointless, but actually showed you something?
• What about the design of your code compared to normal?
• How confident are you in the code you did produce compared to normal?
• If TDD were a real skill that you wanted to learn, what would you focus on next?

Update

I realized after writing this that I should provide some other materials and give credit to those who have influenced me.

1. Gary Bernhardt. Watching his Destroy All Software screencasts is remarkable. He works very hard at his craft and shows excellence.
2. Uncle Bob Martin. He is the author of Clean Code and teaches TDD worldwide.
3. Keith Braithwaite. His workshop on TDD is the basis for this article.