Why do TDD?

So what is test-driven development all about? Why do TDD?

The short version is: TDD is the practice of writing tests before, or in parallel with, the production code. The developer will know immediately whether the code is working as expected without starting the application. Moreover, the tests are run automatically, developers will be alerted immediately if they do changes to the code that introduce defects.

Numerous articles are written about the benefits of TDD. To summarize, TDD gives a higher code quality if it's done right.

Benefits of TDD from a technical point of view

So what's in it for us developers? Let's have a look on some of the benefits of doing TDD.

Bugs are caught earlier

Has it ever happened to you that you have developed something, and someone else (or you) introduces bugs a year later? Perhaps some new functionality was added, or some optimizations were done, and all of a sudden your favourite algorithm failed?

Was it hard to figure out when this bug was introduced and hence hard to fix it? Perhaps the bug even found its way to the customer?

Well, you are not alone! That happens to us all. The good news are; the probability of discovering the bug immediately is much higher if the existing code is covered by tests!

You do rather want to let a test find the defect... ...than having an angry customer find it

Refactor with confidence

Refactor often, they say. Frequent refactoring yields a continuous improvement of architecture as the codebase increases. So how do you know that the refactoring does not introduce defects? By having automated tests, of course! If you can refactor with a lower likelyhood of creating defects, you can refactor more often.

Better architecture

Now that's a bold claim. How can tests enhance the architecture? Because doing TDD with a poor architecture is painful. Good tests and a proper TDD approach requires that the production code follows the SOLID principles. You may not have heard about the SOLID principles, but you do most likely use them. These principles include commonly accepted best practices like the Single Responsibility Principle (let your class do one thing only), decoupling and dependency injection. 

If you write the test first, you are forced to follow these principles. If it turns out that a class is not testable, it usually means that you are violating one or more of these principles. Then it's a good idea to do refactoring, or perhaps the class should be redesigned altogether.

Bottom line is - TDD is an efficient design tool because it encourages a clean and decoupled design. Complex code is hard to test and is a bad idea to begin with!

Where to start

So how do you get started with test-driven development? That's a too large topic to cover in this blog post, but I highly recommend getting a book. You will save yourself from countless hours of frustration if you get a fundamental understanding of writing tests instead of reading random articles on the web.

The Art of Unit Testing by Roy Osherove is a very good book. Make sure that you get the 2nd edition, as this is more updated on tools and methodology.

One last word: remember that test-driven development is not magic. It will not magically solve all your problems and make your codebase bug free tomorrow. It's a tool that, if used correctly, will help you create software with fewer defects, higher quality and better architecture.

TDD is software development done the scientific way. Good luck!