Test Driven Development - The Epiphany

I think that by now, most of us in the development community have heard about Test Driven Development and Behavior Driven Development, but how many people do you know that have consistently applied these practices and got the ROI from it?

I want to share with you the story of how I started down this path, and why I think it's a pretty great way to go.

Also, if you want more, practical information on effective unit testing, check out this post.

The first time I heard about TDD was listening to a tech podcast guest starring "Uncle Bob" Martin himself. He explained his Three Laws for the approach. Here's the gist:

1. Do not write any production code unless it's to make a failing test pass.
2. Do not write any more test code than is necessary to make a test fail.
3. Do not write any more code than is necessary to make the one failing test pass.

My first thought was probably very similar to yours. How much time does this take up? In the real world with very real deadlines, it might not seem pragmatic.

I started to very seriously doubt the usability of this methodology, but he went on to explain that the point is to continuously run the code in a rapid cycle of test, write, and refactor, using the simplest possible solution.

As I thought about the cyclic nature of TDD, I realized that this method of writing code is much like a microcosm for the larger agile process, with similar fixtures and on a much smaller scale (the unit of test). If an iterative approach can work for projects at any scale, why not here?

That was it for me, it finally clicked.

Since that epiphany I've invested in learning everything I could about the art and science of TDD and the Three Laws in practice. Here's the simple procedure I came up with to apply these rules. Try them out yourself some time.

1. Make sure you understand what changes you need to make (it may seem obvious, but bear with me)
   • This is an opportunity to fail early and not waste time on creating the wrong solution.
2. Write a test to validate a single change.
   • Small, iterative changes snowball into high quality code that can be automatically tested the moment it's written.
3. Run the test to make sure it fails, this is important to validate the test logic and any assumptions you've made about the code.
4. Now you can happily make your change knowing that the test will tell you when you're done.
5. Once your test passes, celebrate. You have a working, well tested change.
6. Refactor for readability, cleanliness, and efficiency.
   • Remember to refactor code so that it speaks for itself!
7. Repeat.

That's it! TDD in a nutshell. :-)

Pragmatism Points

• Does it take practice? Yes
• Does it cost more time upfront? Yes
• Does it save massive amounts of your team's time? Yes, after the habit is developed
• Is that upfront time cost worth it? Maybe not. It's not well suited for early stage startups.
• Does it make your developers more productive, your projects easier to manage, and promote a culture of code ownership? Definitely

Did you like this post?

TDD and unit testing in general are HUGE topics, and I'd like to take a dive into the deep end. So leave a comment below to help me improve, and keep an eye out for much more to come.