TDD Cycles Guide
TDD Cycles Guide
Applying TDD Cycles at the System Level, Component Level, and Unit Level.
TDD is NOT just red-green-refactor with Unit Tests.
Many developers believe that there is just one TDD Cycle: Red-Green-Refactor with Unit Tests. After all, most of Uncle Bob's examples show TDD with just Unit Tests.
So the Developer practices TDD at the Unit Test level only.
The Developer finishes the User Story when all the Unit Tests are green.
So the User Story is Done, right?
Wrong.
The QA Engineer says that the User Story isn’t working correctly.
There are a lot of bugs!
What?!
This is TDD the wrong way.
I want to show you how to do TDD the right way so that you don’t just end up with a bunch of passing Unit Tests but rather a User Story that actually works correctly. This is done by applying TDD Cycles at the System, Component, and Unit Levels.
We can apply TDD Cycles at different levels:
1. TDD - System Level:
Acceptance Tests: We use Acceptance Tests to drive the System's implementation (based on the User Story Acceptance Criteria).
External System Contract Tests: We use External System Contract Tests to drive integration with the External Systems.
2. TDD - Component Level:
Component Tests: We need to decompose the system-level behavior (specified by the Acceptance Test) into component-level behavior (specified by the Component Tests). We use the Component Tests to drive the implementation of the Components (Frontend and Backend Microservices).
Contract Tests: We use Contract Tests to specify contracts between the Frontend and Backend. We also use Contract Tests to specify contracts between the Microservices themselves and between Microservices and External Systems. We use Contract Provider Verification Tests to verify that a provider satisfies a consumer.
3. TDD - Unit Level:
Unit Tests: We need to decompose component-level behavior (specified by the Component Test) into unit-level behavior (specified by the Unit Tests). We use the Unit Tests to drive the implementation of application-side business logic within the Component.
Narrow Integration Tests: We use Narrow Integration Tests to drive the implementation of presentation and infrastructure logic within the Component.
Let’s dive into this!
