TDD provides 5 rapid feedback loops

TDD provides 5 rapid feedback loops during software development.

Feedback loops are essential in keeping us on-track towards reaching goals. Getting feedback provides assurance that we’re going in the right direction, or indicates that we need to take corrective action in case we’re going in the wrong direction.

What kind of feedback do we get from TDD? (RED-GREEN-REFACTOR)

1. REQUIREMENT TESTABILITY: Is the requirement testable? If the requirement is not testable (e.g. we have no example or cannot construct an example to verify whether the requirement is met), then it’s pointless to do any implementation (i.e. we’re wasting time without knowing what we expect as the result). In TDD, if we can’t write the test, it means the requirement is not testable, we can’t go further.

2. TEST FALSIFIABILITY: Is the test falsifiable? A test is falsifiable if we saw it failing. This serves as “proof” that later, when we add code that works, that it’s the code that actually made the test pass. This helps us avoid false positives (which occur in the case of tests that always pass). In TDD, the “RED” step is essential because it shows that our test CAN fail.

3. INTERFACE DESIGN: Is the interface consumable? An interface is a contract between the producer and the consumer, it needs to be suitable for both the producer and the consumer. We know that a contract is consumable (usable for the consumer) when the consumer attempts to use it. If an interface is hard for the consumer to use, then this indicates problems in interface design. In TDD, the test is the first consumer.

4. IMPLEMENTATION CORRECTNESS: Does the implementation work correctly? We can say that the implementation works correctly if we’ve seen a failing test, and then only after the code was implemented, that we see the test pass. A working implementation is essential for external quality (satisfying the requirements). In TDD, this refers to the GREEN step.

5. IMPLEMENTATION QUALITY: Is the implementation clean? After the GREEN step, we may see ways how we can make our code clean through refactoring. A clean implementation is essential for internal quality (reducing future maintenance costs). In TDD, this is the REFACTOR step.

The main benefits of this incremental micro-level feedback are:
– Focusing on requirements: the TDD cycle is initiated by writing requirements in an executable form
– Both working code and clean code: the TDD cycle enables developers to be sure that their code works, as well as to safely refactor to clean code

In the above, we talked just about TDD. But how about TLD? TLD also can have the above feedback loops but the difference is that feedback loops are shorter in TDD compared to TLD (we will be looking at that in an upcoming post).

What is your experience with feedback loops in TDD? What benefits do you see? Are there any other feedback loops you experienced?