7 Reasons To Start Doing Test Driven Development

Why should you start doing Test Driven Development (TDD) today? What are the benefits of TDD, and how can it help the developers and business? Let’s explore 7 reasons everyone should be TDD-ing ?

Moving design into code

With test driven development, you create your tests before writing production code*.

Having that in mind, one of the benefits of using TDD is that you need to move your design requirements into code before you even write a single line of business logic.

It means that you need to spend time thinking about good names for your tests. I often create empty tests straightaway after staring to work on a task. Spending time to create well-named test methods can help you quickly spot missing parts in the design.

*By production code I mean the actual business logic except the tests’ code. This is only to differentiate here, but I personally consider my tests part of the production code in real life. Tests are as important as all the code.

Finding edge cases

Going further, if you create many empty tests with well-thought names, you will surely find many edge cases. Thanks to test driven development, you’ll verify the business requirements by your code without writing even a single line of it. Discovering edge cases and boundary conditions will let you clarify the requirements or even change/adjust them before any production code is written ?

Structuring your code beforehand

You’ll see that TDD forces you to think about the code you’re about to write beforehand. You’re going to think about production code to-be-written: how and where to add it, what methods, parameters and classes are needed. Thanks to that, you can quickly notice that maybe the place you’d normally place the new code in is not the best choice. Maybe it requires too much changing instead of modifying.

Such approach leads to taking and rethinking architectural and structural decisions before writing a single line of production code. In the end, it saves you a lot of time. Without TDD, you’d probably just add this new code where you thought it’s appropriate and struggle to refactor it later. And refactoring without tests is dangerous ?

Allowing to refactor

Test driven development is based on red-green-refactor cycle. As soon as your test is green, you can safely (for sure much more safely than without tests, especially if you combine TDD with mutation testing) refactor the code you’ve just written.

In the end, the quality of your code is much higher than it would be without tests. You don’t feel the fear of refactoring, which is a common blocker for improving code quality in legacy systems.

Making implementation very easy

When you move from red to green phases of TDD, it’s time for implementation. From my experience, writing production code that satisfies TDD-produced tests is very easy.

I find it much easier than writing code not covered by TDD-based tests. You exactly know what to do and which tests must pass. Thanks to that, your implementation is minimal – it should only make the test(s) green.

Creating current code documentation

Implementing a new feature with test driven development will leave you with a comprehensive set of tests. From my experience, I write few times more tests with TDD than in a “traditional” tests-after-code mode.

As a nice side effect, you’re building and growing the only possible, current documentation of your code – set of your tests. Only tests can tell you the truth about your code. It can’t be achieved with any other kind of documentation. Notice one more advantage – you’re creating documentation… without writing any documentation! ?

Current, well-named tests are very helpful not only for developers, but also for the so-called business people.

Spotting architectural problems

Last but not least, test driven development helps to solve application’s architectural problems. Tests should be relatively easy to write. If the test is hard to write before production code exists, it might mean that the architecture of your solution is wrong. There’s a problem somewhere that should be addressed.

That’s why it’s very important to start working with TDD as early as possible in your project. There might be some cases where TDD it not suitable (maybe I’ll write a separate article about it ?), but in quite mature and stable projects, it should be a gold standard. Altering the architecture is much easier early in the project.