TDD / BDD / SDD Workflows

Comparing the three approaches

TDD with Claude: Red-Green-Refactor

The classic cycle, made explicit in prompts to prevent Claude from jumping straight to implementation.

# RED phase: ask for the failing test first
> "Write a FAILING test for isValidEmail().
   The function does not exist yet."

# GREEN phase: minimal implementation
> "Write the minimal code to make this test pass."

# REFACTOR phase: improvement
> "Improve the implementation. Tests must
   stay green."

Being explicit about “FAILING” and “does not exist yet” is essential — otherwise Claude tends to write test and implementation together.

BDD with Claude: Given/When/Then

> "Describe the behavior of the login page
   as Gherkin scenarios, then implement."

# Claude generates:
# Scenario: Login with valid credentials
#   Given a registered user with email test@ex.com
#   When they submit the form with the correct password
#   Then they are redirected to their dashboard

The benefit: scenarios serve simultaneously as spec, documentation and test base, in a language readable by non-developers.

SDD with Claude: Spec first

Write the complete specification before the first line of code. Claude then uses the spec as a reference throughout the implementation.

> "Here is the spec for POST /auth/login endpoint
   [paste the spec]. Implement section by section
   respecting every constraint."

Verification Loops: the founding principle

All three methods rely on the same principle identified by Boris Cherny: an agent that can “see” what it has produced delivers better results. Without a verification mechanism, Claude iterates blindly.

Chain-of-Verification

Cross-validation pattern (arXiv:2309.11495) to reduce hallucinations: Claude generates a response, then generates verification questions about that response, then answers those questions to detect inconsistencies.

Applicable when result correctness is critical and automated tests are insufficient (complex algorithms, subtle business logic).

Integration with Tasks API

# Create the TDD hierarchy in Tasks API
TaskCreate: { title: "Write failing tests for auth" }
TaskCreate: {
  title: "Implement auth to pass the tests",
  blockedBy: ["task-tests-failing"]
}
TaskCreate: {
  title: "Refactor auth",
  blockedBy: ["task-impl-auth"]
}

The Red-Green-Refactor cycle becomes traceable and persistent across sessions.