Skills / Engineering

Test-Driven Development (TDD)

Clean code that works.

Kent Beck's Test-Driven Development is a software development discipline built around a strict three-phase cycle — Red, Green, Refactor — in which every line of production code is justified by a failing test written moments before it. The methodology is not about testing; it uses tests to drive design, forcing small, decoupled, working increments at every step. Formalized in Beck's 2002 book with two complete worked examples, TDD gives developers a precise decision rule for every moment of the coding loop.

By Kent Beck  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisTest-Driven Development (TDD)

Input

“I need to write a function that converts temperature from Celsius to Fahrenheit. Python and pytest. Seems simple but I want to practice proper TDD.”

Diagnosis

Let's do this the TDD way — which means we don't touch production code until we have a failing test telling us what to write.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Write a failing test first — let it tell you exactly what code to write next

TDD operates through the Red-Green-Refactor cycle: (1) Red — write the smallest possible failing test that captures one desired behavior; (2) Green — write the minimum production code to make that test pass, even if it means hard-coding a return value ('Fake It Till You Make It'); (3) Refactor — clean up all duplication and improve design while keeping every test green. Beck prescribes starting each feature by writing a Test List — enumerating all known cases before touching code — and uses Triangulation (adding a second test with a different example) to force real generalization when a fake implementation has gone far enough. The Obvious Implementation shortcut lets developers skip faking when the solution is clear, but Beck's default is always the smallest safe step. This tight loop, completable in minutes, produces emergent, decoupled design as a side effect rather than an upfront requirement.

The problem

Most developers write code they hope works, then add tests as an afterthought — or skip them entirely under deadline pressure. This produces coupled, fragile codebases where bugs surface in QA or production, debugging sessions steal hours from building, and no one refactors because there is no safety net. TDD doesn't just add tests; it inverts the entire workflow so that untested code becomes literally unwritable by construction.

The solution

By following the Red-Green-Refactor cycle one baby step at a time, you will always know exactly what to write next, always have a passing test suite as a safety net, and produce a codebase whose design emerged from real constraints rather than speculation.

You bring

A feature description, user story, or requirement you want to implement
The programming language and test framework you're using (e.g., Python/pytest, JS/Jest, Java/JUnit, Ruby/RSpec)
Any existing code context — class names, data structures, or interfaces already in place
Your current position in the cycle — a failing test, a passing test, or working code in need of cleanup

You get

A Test List enumerating all known cases before you write a single line of production code
A minimal failing test (Red) written Assert-First, testing exactly one behavior
The smallest possible Green implementation — including Fake It stubs when appropriate — with a clear path to generalization via Triangulation
A refactoring checklist that identifies duplication and design smells once tests are green, with every suggested change small enough to preserve the full green suite

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“You have a new feature to write, so you open a blank file and start coding — building out the logic, the conditionals, the edge case handling. An hour in, you write some tests to verify it. Two of them fail. You're now debugging code you just wrote, guessing which assumption was wrong, and the design has already calcified around untested behavior.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Test-Driven Development (TDD)

“You write a Test List of seven cases before touching implementation. Each Red phase takes two minutes, each Green phase takes three. After five cycles, you have a fully tested, passing module — and its design is naturally decoupled because every piece of behavior was extracted only when a failing test demanded it. The Refactor phase finds one naming issue and removes duplicated setup. The test suite is the documentation.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Test-Driven Development (TDD)Claude

Test-Driven Development (TDD)

Let's do this the TDD way — which means we don't touch production code until we have a failing test telling us what to write. First step before any code: build a Test List together. Tell me the feature or behavior you want to implement and your language and test framework.

I need to write a function that converts temperature from Celsius to Fahrenheit. Python and pytest. Seems simple but I want to practice proper TDD.

Good kata for learning the cycle. Before touching implementation, here's your Test List:

```[ ] 0°C → 32°F (freezing — simplest possible case)[ ] 100°C → 212°F (boiling — forces generalization away from Fake It)[ ] -40°C → -40°F (crossover point — negative input)[ ] 37°C → 98.6°F (body temp — floating point output)[ ] Non-numeric input → raises TypeError```

Any cases missing? Once the list looks right, we pick the simplest item and write the first failing test — Red phase.

That looks complete. Let's start with the freezing point.

Assert First — write the assertion before the setup. Here's your Red phase test:

```python# test_temperature.pydef test_freezing_point_converts_to_32_fahrenheit(): assert celsius_to_fahrenheit(0) == 32```

Run this now. You should get `NameError: name 'celsius_to_fahrenheit' is not defined`. That is the correct red — a genuine missing behavior, not a syntax error. Confirm you see that failure, then we write the minimum Green code.

Got the NameError. Now what — do I write the real formula?

Not yet. Beck's rule: write the minimum code to pass this specific test — which means Fake It first:

```python# temperature.pydef celsius_to_fahrenheit(celsius): return 32```

Hard-coded. Run the test — it goes green. This is intentional: you haven't earned the formula yet. The next test on your list (100°C → 212°F) is your Triangulation test. It will make `return 32` fail and force the real implementation. Ready to write that second test?

Green with the fake. Writing the second test now — and I can see how it breaks the hard-coded return.

Exactly — that's Triangulation doing its job. The two failing examples together demand the real formula:

```pythondef test_boiling_point_converts_to_212_fahrenheit(): assert celsius_to_fahrenheit(100) == 212```

Now write the Obvious Implementation — `(celsius * 9/5) + 32`. Run both tests green, then Refactor phase: scan both files for duplication or naming issues before moving to the next item on your Test List. The design emerged from two tests, not from planning.

Reply to Test-Driven Development (TDD)…

What the skill is doing

01Test List Generation

02Red Phase Failing Test Design

03Green Phase Implementation Strategy (Fake It / Obvious Implementation)

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

TDTest-Driven Development (TDD)typing…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

I need to write a function that converts temperature from Celsius to Fahrenheit. Python and pytest. Seems simple but I want to practice proper TDD.9:14✓✓

Let's do this the TDD way — which means we don't touch production code until we have a failing test telling us what to write.9:14

First step before any code: build a Test List together.9:15

Tell me the feature or behavior you want to implement and your language and test framework.9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Test List Generation

Before writing any code, enumerate all the cases your implementation must handle — happy paths, edge cases, error conditions, and boundary values. Getting everything out of your head and into an explicit list prevents scope creep mid-cycle and gives you a clear, finite runway.

◦ MethodBased on Beck's 'Test List' pattern from TDD by Example: 'When you start a new feature, jot down a list of all the tests you know you will need to write' — the list is a living scratch pad, not a fixed contract.

CapabilityC-02

Red Phase Failing Test Design

Write the smallest possible failing test for one item on your Test List, using the 'Assert First' pattern — beginning with the assertion you want to be true, then working backwards to the setup. The test must fail for the right reason before you touch production code.

◦ MethodBased on Beck's 'Assert First' and 'One Failing Test at a Time' patterns: write the assertion before the body, ensuring every test captures exactly one intended behavior.

CapabilityC-03

Green Phase Implementation Strategy (Fake It / Obvious Implementation)

Choose between 'Fake It Till You Make It' (hard-code the simplest return value that passes) and 'Obvious Implementation' (write the real solution directly) based on how confident you are in the correct path. This keeps steps honest and prevents over-engineering during the Green phase.

◦ MethodBased on Beck's explicit decision rule: default to Fake It when in doubt, switch to Obvious Implementation when the correct code is fully clear — never write more than the failing test demands.

CapabilityC-04

Triangulation & Generalization Coaching

When a fake or hard-coded implementation has passed its first test, write a second test with a different concrete example to force real generalization. Triangulation is the disciplined escape from fake code — it lets the tests do the driving rather than your assumptions about what the general solution should look like.

◦ MethodBased on Beck's 'Triangulate' pattern: 'Only generalize code when you have two examples that require it' — the second test forces the real implementation without requiring the developer to guess the right abstraction upfront.

CapabilityC-05

Refactor Phase Code Review

Once all tests are green, scan both production code and test code for duplication, poor naming, and structural coupling, then suggest refactoring steps that preserve the green suite. Refactoring is strictly separated from the Green phase — no behavior changes while cleaning up.

◦ MethodBased on Beck's core principle that the Refactor phase is the only time to improve design, and that any refactoring step that breaks a test was too large — roll back and take smaller steps.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

TDD Test List

A prioritized enumeration of all test cases for a given feature — happy paths, edge cases, error conditions — written before any production code. Serves as your roadmap and scope boundary for the entire development cycle.

OutputD-02

Red-Green-Refactor Cycle Log

A running record of each mini-cycle: the failing test written, the implementation strategy chosen (Fake It or Obvious), and the refactoring applied. Makes the TDD discipline visible and reviewable by you or your team.

OutputD-03

Fake-It-to-Real Generalization Trace

A documented path from a hard-coded fake implementation through successive Triangulation tests to a real, generalized solution — showing exactly how the tests drove the design rather than speculation.

OutputD-04

Refactor Checklist

A post-green checklist of duplication, naming issues, and structural smells in both production and test code, with suggested refactoring steps each small enough to keep the suite fully green throughout.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Kent Beck

Kent Beck is the creator of Extreme Programming (XP) and the author of 'Test-Driven Development: By Example' (Addison-Wesley, 2002), widely regarded as the definitive text on the discipline. He co-created JUnit with Erich Gamma — the framework that spawned pytest, RSpec, Jest, and virtually every xUnit-style test runner in use today. Beck was a signatory of the Agile Manifesto and later served as a Distinguished Engineer at Meta, applying and teaching TDD on production systems at scale.

Status · Inspired by Kent Beck’s work — not yet claimed. Are you Kent Beck?

Primary sourceS-01

Test-Driven Development: By Example (Addison-Wesley, 2002)

by Kent Beck

Creator of Extreme Programming; co-creator of JUnit with Erich Gamma; Agile Manifesto signatory; author of 'Test-Driven Development: By Example' (Addison-Wesley, 2002).

Read the original ↗

Citationoreilly.com

In the build queue

Be first to run it.

Test-Driven Development (TDD) is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchI want to build [describe your feature or function] in [your language/framework]. Let's do it TDD — start by helping me write a complete Test List before I touch any production code.