The 3 Laws of TDD: Focus on One Thing at a Time

Click to play

January 23, 2018


When I was first learning test-driven development (TDD), I'd try to get to the First Step (a failing test) by writing a fully-formed test. But it often took a lot fiddling to get that test to run and fail. Sometimes this was because the production code took several steps to set up. Sometimes it was because the test code wasn't right.

One of the tricky parts of TDD is that we're creating two streams of code in parallel: the test code, and the production code. Two things changing at the same time… that's a hard thing to keep in your head!

Code snippet sample

Improve your test writing “Flow.”

Sign up to get my test-oriented code snippets.

The 3 Laws: Managing Parallel Changes

That's where the 3 Laws of TDD come in. They constrain us to change only one thing at a time. Here they are:

  1. Write no production code except to pass a failing test.
  2. Write only enough of a test to demonstrate a failure. (Not compiling is also a valid failure.)
  3. Write only enough production code to pass the test.

It's hard to tell how they work just from reading them over. So watch the video above! I give a demonstration of the 3 Laws, as they play out in Swift. (Bonus: There's a mock object, too.)

Try It Yourself, See the Difference

The next time you TDD a component, go ahead and do it the typical way, by writing the entire test. Observe:

  • How much test code you write in one shot.
  • How much production code you write in one shot.
  • How long you go without feedback.

Then try it again, but apply the 3 Laws. Notice the difference. Do you see how this activates even tighter feedback loops?

Remember, getting rapid feedback is a huge benefit of test-driven development. So why not dial it "up to 11"?

Give it a try. Then post your questions or observations in the comments below!

Did you like the video? Consider having me teach my TDD for iOS workshop at your company.

What are the 3 Laws of #TDD, and how do they improve feedback time?

Click to Tweet

How Many Code Smells Can You Find in This Short Method?

Jon Reid

About the author

Programming was fun when I was a kid. But working in Silicon Valley, I saw poor code lead to fear, with real human costs. Looking for ways to make my life better, I learned about Extreme Programming, including unit testing, test-driven development (TDD), and refactoring. Programming became fun again! I've now been doing TDD in Apple environments for 20 years. I'm committed to software crafting as a discipline, hoping we can all reach greater effectiveness and joy. Now a coach with Industrial Logic!

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Never miss a good story!

    Want to make sure you get notified when I release my next article or video? Then sign up here to subscribe to my newsletter. Plus, you’ll get access to the test-oriented code snippets I use every day!