What is test-driven development and which three rules does it follow?

What is test-driven development (TDD)?

Test-driven development (TDD for short) is a programming approach in which developers write production code in response to a test case; as opposed to the traditional process where code is written first, and relevant test cases are created later. In other words, in TDD, tests guide the implementation. This results in easier-to-maintain and better-quality code, but at the same time, increases the initial development time.

TDD is an effective specification technique that ensures effective unit testing and results through 100% test coverage. However, it doesn’t fully replace traditional testing.

How to do test-driven development?

Robert Cecil Martin, also known as Uncle Bob, came up with three rules that describe the TDD framework in a nutshell and are a good starting point for your own practice:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Let’s see how to transfer Uncle Bob’s words into practice when we’re implementing Agile when developing digital products (source).

What is test-driven development in Agile?

Test-driven development is an Agile method – the process is iterative and incremental. The TDD process is composed of short development iterations called the red, green, refactor cycle. The three phases of the TDD cycle are:

1. Red: think about what you want to develop and write a test that will validate whether the code behaves as you expected. At this point, you have only the test, not the code responsible for the new functionality, so the test fails – and that’s what we call a red test.
2. Green: aim to pass the test in the easiest possible way. Your goal here is to find the solution quickly, so you write minimal code, without worrying about optimizations. At the end of phase two, your code should pass the test – and that’s a green test.
3. Refactor: find ways to improve your existing implementation. What is code refactoring? At the end of each cycle, you refine the code, eliminate duplication, improve its efficiency, etc. and re-run the tests to ensure that your implementation meets the initial criteria.

Development cycles in test-driven development are very short, as project teams turn requirements into very specific test cases. Being an Agile method, the TDD cycles are repetitive, and the end of a refactor phase initiates the next iteration.

You might be also interested in the article:

Everything you should know about user testing

Advantages and benefits of TDD

The benefits of test-driven development go beyond simply validating code. TDD can also drive the overall product design and development, and play a significant role in optimizing the delivery process.

The primary advantages of TDD are:

• Improved design of the system;
• Better code quality and flexibility;
• Good documentation as a byproduct;
• Lower development costs and increased developer productivity;
• Enhanced developer satisfaction.

Let’s dig into each of the above-listed advantages of test-driven development.

Improved design of the system

TDD focuses on one small feature at a time. The code becomes easier to check when you write the test first, and that results in a clear interface. So, by following a test-driven development process, you achieve a modular, easy-to-understand, maintain, extend, test, and refactor structure for your application.

Better code quality and flexibility

According to a 2020 IEEE publication, test-driven development supports the development teams in delivering high-quality products with fewer bugs and cleaner code (source). Additionally, the clear structure and focus on requirements allow for easier maintenance and future modifications for both the engineers involved in the project from the beginning and anybody who joins the team further down the line.

Good documentation as a byproduct

Test code demonstrates how to use the code and serves as a well-structured and easy-to-follow documentation itself. That way, the documentation follows the changes in the project without additional time and effort.

Lower development costs and increased developer productivity

At the end of the day, all the advantages mentioned above result in cost reduction and enhanced team performance. In a joint study carried out by Microsoft and IBM, four development teams adopted TDD, resulting in a 40-90% reduction in defect density (source). At the same time, they recorded a 15-35% increase in time to complete the projects, which, they said, was offset by the decreased maintenance costs due to the enhancement in quality.

Enhanced developer satisfaction

A team approach can make or break a project, and happy teams are more effective and communicate better. It’s yet another important aspect of product development, especially when we’re talking about software, where talent shortage is one of the biggest concerns organizations face nowadays.

You might be also interested in the article:

Technical debt - how to build future-proof digital products?

Test-Driven Development: By Example — The book

TDD was developed by Kent Beck in the 1990s and later described in his book called Test Driven Development: By Example. This publication is probably the most reliable source of in-depth practical information about test-driven development. It follows two TDD projects from start to finish, describing techniques software teams can easily adapt to significantly increase the quality of their work. Definitely worth a read if you want to embrace test-driven development in your product development team.

You might be also interested in the article:

How to improve productivity in agile scrum teams

TDD – a recipe for better code quality

Test-driven development creates better code and, in the long run, is more time- and cost-efficient than traditional programming frameworks. Hopefully, this article helped you understand both the philosophy and the practical side of TDD, and now you’re ready to try incorporating it into your software development practice.