Module 5: TDD/BDD¶

Table of Contents¶

Learning Objectives
1. Theory: Test-Driven Development
2. Prerequisite: Fix Requirements and INFRA Stories
3. Exercise Part 1: Manual TDD Cycle
4. Exercise Part 2: Build and Use the TDD/BDD Agent
References

Learning Objectives¶

By the end of this module you will:

Understand the Red-Green-Refactor cycle and why tests come first
Know the difference between TDD (bottom-up) and BDD (top-down)
Write testable acceptance criteria using GIVEN-WHEN-THEN
Apply Green Bar patterns: Fake It, Triangulate, Obvious Implementation
Know when and how to refactor safely
Build a Kiro CLI agent that implements your kata using strict TDD discipline

1. Theory: Test-Driven Development¶

1.1 Why TDD?¶

TDD was invented in the punch card era of the 1950s. Computer time was scarce and expensive — you might wait days for your 30-minute slot. So engineers developed a discipline: specify the expected output first (punch an output card), then write the program (punch input cards), then verify (compare cards).

They were doing Test-Driven Development before the term existed. The constraint of expensive feedback forced them to think before coding.

Today we have instant feedback, but many developers have lost that discipline. TDD brings it back — not because computer time is scarce, but because good design thinking is scarce.

At one large European OEM, with 500 million lines of code and 160,000 CI jobs per day, TDD was the only way 2,000+ developers could work on the same codebase without breaking each other’s work. At another automotive platform project, teams that adopted TDD delivered 40% faster with 35% fewer defects.

1.2 The Red-Green-Refactor Cycle¶

The heartbeat of TDD:

🔴 RED     → Write a failing test
✅ GREEN   → Write just enough code to make it pass
♻️ REFACTOR → Improve the code while tests protect you

Rules:

Write one test. Run it. It must fail (RED).
Write the simplest code that makes the test pass (GREEN).
Look for refactoring opportunities. Clean up. Run tests again.
Repeat.

You write one test at a time. You do not move to the next test until you are satisfied with how your code looks.

Red-Green-Refactor Cycle

1.3 TDD Is a Design Technique¶

TDD is not primarily a testing technique — it’s a design technique. The tests are valuable, but the real value is in the thinking process TDD forces you through.

When you write the test first:

You think about behavior before implementation
You consider the interface before the internals
You identify dependencies before they become entangled
You design for testability, which means designing for modularity

A senior developer told me: “I used to think TDD was about catching bugs. Now I realize it’s about not creating bugs in the first place by forcing better design.”

1.4 Behavior-Driven Development (BDD)¶

BDD is the top-down complement to TDD’s bottom-up approach. While TDD starts with unit tests and builds upward, BDD starts with user behavior and works downward.

BDD uses the GIVEN-WHEN-THEN format from Module 3:

GIVEN the account balance is €100
WHEN the customer withdraws €30
THEN the balance should be €70

This maps directly to test code:

def test_withdrawal_reduces_balance():
    # GIVEN
    account = Account(balance=100)

    # WHEN
    account.withdraw(30)

    # THEN
    assert account.balance == 70

BDD key principles:

Test method names should be sentences describing behavior
Ask: “What’s the next most important thing the system doesn’t do?”
Requirements are behavior — acceptance criteria are scenarios
Scenarios become executable specifications

1.5 Properties of Good Tests¶

Property	Meaning
Understandable	Anyone can read the test and know what it verifies
Maintainable	Changing implementation doesn’t break unrelated tests
Repeatable	Same result every time, no external dependencies
Necessary	Every test verifies a distinct behavior
Granular	One test = one behavior = one reason to fail
Fast	The full suite runs in seconds, not minutes

Isolated tests: Tests should not affect one another. One broken test should expose one problem. Tests must be order-independent.

Three types of tests in TDD:

Test a return value or exception
Test a change in state
Test an interaction (mock/spy)

1.6 Green Bar Patterns¶

When the test is RED, use these patterns to make it GREEN:

Fake It (‘Til You Make It) — Return a constant. Having something running is better than not having something running. The duplication between test and fake implementation drives abstraction.

def calculate_tax(amount):
    return 10  # Fake it — we know the test expects 10

Triangulate — Abstract only when you have two or more examples. Use triangulation when you’re unsure about the correct abstraction.

# Test 1: calculate_tax(100) == 10
# Test 2: calculate_tax(200) == 20
# Now you MUST generalize: return amount * 0.10

Obvious Implementation — When you’re sure you know how to implement it, go ahead. But if you’re surprised by red bars, fall back to Fake It. Keep track of how often you’re surprised — that tells you when to slow down.

Green Bar Patterns

1.7 Refactoring: The Third Step¶

Refactoring means changing software to improve its internal structure while preserving its behavior.

When to refactor:

Only during the GREEN stage — never refactor on RED
When it becomes hard to write the next test
When resolving technical debt
When code readability can be improved

Principles:

Refactor in small steps
Run tests frequently — they’re your safety net
Eliminate duplicated code
Use meaningful variable names
Apply the Two Hats rule: one hat for adding functionality, one hat for improving design — never both at the same time

When NOT to refactor:

The code doesn’t work (fix it first)
It’s cheaper to rewrite from scratch
You’re close to a deadline (note the tech debt, move on)

1.8 Implementation Order: INFRA → BE → FE → E2E¶

From Module 3, your stories are decomposed into sub-stories. The implementation order matters:

INFRA stories → Deploy infrastructure (Docker, configs)
BE stories    → Implement business logic, API endpoints
FE stories    → Build UI components (if applicable)
E2E tests     → Verify the full flow works end-to-end

Implementation Order

You can’t build a UI for an API that doesn’t exist. You can’t deploy code without infrastructure. Follow the order.

For your kata, INFRA means your Docker setup (from Module 4). BE means your core logic and tests. FE and E2E may not apply depending on your kata.

1.9 One Test at a Time¶

This is the most important rule and the hardest to follow:

Write only ONE test at a time. Implement only ONE test at a time.

Do not write three tests and then implement all three. Do not write a test and then implement more than what’s needed to pass it.

The cycle is:

Pick the next scenario from your user story
Write ONE test for that scenario
Run it — confirm RED
Write just enough code to make it GREEN
Run ALL tests — confirm no regressions
Refactor if needed
Commit (test is GREEN = safe to commit)
Move to the next scenario

TDD Cycle

Once a test is GREEN, commit. Your Git history should show the RED-GREEN-REFACTOR rhythm clearly.

2. Prerequisite: Fix Requirements and INFRA Stories¶

Before implementing with TDD, you need to update your Module 3 output:

Step 1: Update Requirements Agent¶

Your requirements agent (Module 3) generated INFRA stories that assumed AWS deployment. Since your kata runs locally in Docker (Module 4), you need to update the agent to generate Docker-based INFRA stories instead.

Update your requirements-agent.json to force local deployment:

INFRA stories should reference Docker containers, not Lambda/DynamoDB
The deployment target is docker build + docker run, not SAM/CloudFormation
Test execution happens inside Docker via pytest

Step 2: Regenerate INFRA Stories¶

Use your updated requirements agent to regenerate the INFRA sub-stories for your kata. The new INFRA stories should cover:

Dockerfile builds successfully
Test suite runs inside Docker container
Dependencies are installed correctly
Project structure supports pytest discovery

Step 3: Verify INFRA Stories Pass¶

Your Module 4 pipeline should already satisfy these INFRA stories. Run your CI pipeline to confirm:

docker build -t kata-tests .
docker run --rm kata-tests

If this passes, your INFRA stories are GREEN and you can move to BE stories.

3. Exercise Part 1: Manual TDD Cycle¶

Goal¶

Practice the RED-GREEN-REFACTOR cycle manually on one BE scenario from your kata before automating it with an agent.

Step 1: Pick a Scenario¶

Choose one BE scenario from your user stories (Module 3). It should be simple enough to implement in one sitting.

Step 2: Write the Test (RED)¶

Write a single test for that scenario using pytest and GIVEN-WHEN-THEN:

def test_scenario_name():
    # GIVEN
    # ... setup

    # WHEN
    # ... action

    # THEN
    assert ...  # expected outcome

Run it. Confirm it fails.

Step 3: Make It Pass (GREEN)¶

Write the simplest code that makes the test pass. Don’t over-engineer. Fake It if needed.

Run the test. Confirm it passes. Run ALL tests. Confirm no regressions.

Step 4: Refactor¶

Look at your code. Can you improve naming? Remove duplication? Simplify?

Make changes. Run tests after each change.

Step 5: Commit¶

git add .
git commit -m "#<issue> feat(<scope>): implement <scenario description>"

Module 5: TDD/BDD¶

Table of Contents¶

Learning Objectives¶

1. Theory: Test-Driven Development¶

1.1 Why TDD?¶

1.2 The Red-Green-Refactor Cycle¶

1.3 TDD Is a Design Technique¶

1.4 Behavior-Driven Development (BDD)¶

1.5 Properties of Good Tests¶

1.6 Green Bar Patterns¶

1.7 Refactoring: The Third Step¶

1.8 Implementation Order: INFRA → BE → FE → E2E¶

1.9 One Test at a Time¶

2. Prerequisite: Fix Requirements and INFRA Stories¶

Step 1: Update Requirements Agent¶

Step 2: Regenerate INFRA Stories¶

Step 3: Verify INFRA Stories Pass¶

3. Exercise Part 1: Manual TDD Cycle¶

Goal¶

Step 1: Pick a Scenario¶

Step 2: Write the Test (RED)¶

Step 3: Make It Pass (GREEN)¶

Step 4: Refactor¶

Step 5: Commit¶

4. Exercise Part 2: Build and Use the TDD/BDD Agent¶

Goal¶

Step 1: Build the TDD/BDD Agent¶

Step 2: Configure the Agent¶

Step 3: Use the Agent¶

The Full Multi-Agent Workflow¶

Step 4: Verify TDD Discipline in Git History¶

Step 5: Commit via Git Agent¶

Step 6: Add Instructor as Reviewer and Merge¶

Acceptance Criteria¶

References¶

Exercise Checklist¶

Module 5: TDD/BDD — Exercise Checklist¶

Prerequisite: Fix Requirements and INFRA Stories¶

Step 1: Update Requirements Agent¶

Step 2: Regenerate INFRA Stories¶

Step 3: Verify INFRA Stories Pass¶

Part 1: Manual TDD Cycle¶

Step 1: Pick a Scenario¶

Step 2: Write the Test (RED)¶

Step 3: Make It Pass (GREEN)¶

Step 4: Refactor¶

Step 5: Commit (only on GREEN!)¶

Part 2: Build and Use the TDD/BDD Agent¶

Step 1: Build the TDD/BDD Agent¶

Step 2: Multi-Agent Workflow (at least one complete story)¶

Step 3: Verify TDD Discipline¶

Step 4: Review and Merge¶