The Real Reasons for Doing Test-Driven Development 💎

Why do people apply TDD? Here’s a secret: it’s not for the tests. Learn about the actual goal and values hidden under the surface of Test-Driven Development.

What Are the Real Reasons for Doing TDD? 🧼

Test-Driven Development (TDD) is a controversial topic amongst developers. After many years of doing TDD daily, I think part of the reason is that some people do not fully grasp the reasons behind TDD.

Let’s get the biggest misconception out of the way first: TDD is not about testing. It is a vehicle to drive development.

The goal, according to Test-Driven Development: By Example, is simple yet powerful:

Clean Code That Works

I love that brief explanation, and if there is one thing you take away from reading this post, that should be it. However, specific reasons for doing TDD are best expressed in terms of Extreme Programming’s values. These are:

• Feedback
• Simplicity
• Courage
• Communication
• Respect

TDD and the Values of XP 🧗

TDD offers many benefits, but I prefer a different perspective that delves a little deeper. In my opinion, Extreme Programming (XP) best describes the reasons for doing TDD.

Kent Beck defined five values in Extreme Programming Explained (a book I highly recommend) which form the foundation of everything it entails. As you will see, TDD is also built on top of that foundation.

But first, a few words about why all this even matters.

Why do Values Matter in the First Place? 🏃

As I mentioned, TDD is the subject of quite some controversy amongst developers. Software engineers either love or hate it, and I wonder if those who don’t like it truly understand the purpose of TDD.

Stretching doesn’t make sense without knowing its purpose

It’s like not wanting to stretch before going out for a run simply because you are unaware that it prevents injuries. Without that knowledge, stretching seems like a waste of time and effort.

The underlying values of a practice give it its meaning.

Improving Feedback by Using TDD 🧭

Firstly, TDD is one of the best ways to generate feedback. Feedback on what? On each one of these attributes:

• Correctness. Simply put, does the code do what you want? The crucial differentiator is that with TDD, you get this while you’re still coding up the problem. No need for print statements or playing compiler in your head to figure out what the code is doing.
• Quality. A superpower of TDD. It will force you to write testable code, i.e., loosely coupled and highly cohesive, which means your code has a higher quality. If the testing becomes difficult, it is a tell-tale sign your design could use improvement. Thus, TDD is an effective way to get feedback on your code’s internal quality.
• Progress. Since you start specifying behavior as a failing test, you know exactly when you’re done: once the test is green. Combining this with Acceptance Test-Driven Development or Behavior-Driven Development amplifies the feedback to the feature level.

In essence TDD employs tests to generate feedback. Like a compass, it constantly shows you whether you’re heading in the right direction.

Achieving Simplicity with TDD ❤️

Secondly, Test-Driven Development is a great way to write simpler code. Simplicity is difficult to achieve in programming, but it is equally crucial to pursue. It helps manage complexity. The definition of simplicity that I like best comes from the agile manifesto:

Simplicity–the art of maximizing the amount of work not done–is essential.

But how does TDD achieve this magical thing?

Firstly, it forces you to express the behavior you need upfront unambiguously. You should end up writing exactly the code you need, following the “You Aren’t Gonna Need It” principle. An experienced TDD’er aims to go from red to green as quickly as possible, and simplicity is a surefire way to do so.

Furthermore, the last step in the tdd cycle is refactoring. This continuous refactoring cycle results in more readable and simpler code.

Becoming Courageous by Applying TDD 🦁

Thirdly, TDD supplies you with a healthy dose of courage. Courage seems like an odd value to associate with TDD, but it’s the value that gets the most attention in Test-Driven Development: by Example. In the book, Kent describes courage as “managing fear” and explains how TDD is an effective means to do so.

TDD is all about managing fear

What does fear mean?

Have you ever had to change some incomprehensible code? How about code missing (good) tests? The feeling you were experiencing was probably fear. You were afraid that you might break the code. TDD should result in a codebase where you never have to feel this type of fear again because you can rely on a solid set of tests. These give you certainty at the press of a button, courage on demand.

Another way TDD helps manage fear is when you’re unsure how to continue. Sometimes you don’t know how to solve a problem, and fear will rear its ugly head. Fear makes solving problems harder. TDD allows you to shift gears and solve the problem one tiny step at a time. Taking these baby steps will enable you to circumvent fear and start making progress.

TDD’s Effects on Communication 🗣️

Communication is the fourth compelling benefit of TDD. A result of TDD is a solid set of tests. When done correctly, well-written tests communicate the system’s behavior to its readers.

Tests effectively document the code’s intent and are my go-to place for comprehending unfamiliar code. Imagine what it would be like if your entire codebase had tests explaining what code does under specific conditions. Wouldn’t that be great?

Therefore whenever I write code in a TDD fashion, I always keep the future reader of the code and the tests in mind. You should empathize with the reader. My goal is to prevent head-scratching moments for that person, and tests allow me to achieve that goal.

Doing TDD Shows Respect 🙇

Lastly, applying TDD is a sign of respect. By using it, you show respect to your:

• fellow team members
• stakeholders
• users

Why? Think back to the goal of TDD: clean code that works.

For your team members, this means maintainable, well-documented code that is a pleasure to work with. You respect your stakeholders since you write just enough code to achieve the result they are interested in. It also enables you to maintain a sustainable pace of feature delivery by keeping technical debt in check. Finally, your users will enjoy a stable, well-crafted product with fewer defects.

Summary 📝

Test-Driven Development is an effective programming practice that leads to simple, well-designed code. But applying it without understanding the underlying values makes it an empty shell. You don’t do TDD for the sake of TDD.

TDD follows the overarching values of XP. When applied correctly, you can expect it to improve communication , simplify your code, increase feedback , reduce fear , and show respect to all parties involved. Doesn’t that sound amazing?

Are you doing TDD? What effects of TDD surprised you? Share your thoughts in the comment section.

Further Reading 📚

• Extreme Programming Explained
• Test-Driven Development: By Example
• Growing Object-Oriented Software, Guided by Tests