General TDD Guidelines

At this point, it’s worth summarizing which guidelines and best practices should be followed when we’re about to write a program with the test-driven development approach. Below is a list of rules and advice worth following when dealing with TDD. They are not meant to create solutions that can always be applied to every scenario, but rather, they should be evaluated based on individual use cases that are different from project to project.

Respect the Red-Green-Refactor cycle

This simply means that everything we’ll do in our project should be done in the right phase. As an example, we can’t fix broken functionalities in the Refactor phase before we’re done in the Green phase. We need to be self-disciplined and try to respect the TDD constraints.

Think about use-cases

In order to develop any unit within our program, we need to have a clear idea of the requirements. In other words, we must know what the function expects, what it’s supposed to return back, and how our code will be used by the consumers.

Don’t overcomplicate ahead of time

TDD is meant to keep the solution simple and efficient. We should not introduce any useless complexity ahead of time. The latter should be introduced in a gradual way when our business requirements are getting more complex.

Quick feedback

The tests should be as fast as possible. If we find out that a test takes a while to execute, maybe it’s better to rethink it. Tests should rely on mocks that will take very little time to execute and give back the result.

Smallest steps

Even if, at first glimpse, it may sound dumb, it’s essential to take only small steps to enter a new phase of the TDD cycle. To fix a faulty test, we may be tempted to write a full-fledged solution, but this breaks the TDD constraint and can potentially harm our software by introducing buggy code or code smells. As an example, to exit from the Red phase usually, we have to hard-code the desired result in the function.