Skip to content

Test-Driven Development

Write one failing test, implement to pass, repeat. Tests provide verification points that keep agents focused and prevent drift.

Pattern

Step 1: Write tasks first, one test per task

One task = one test = one externally observable behavior.

Task 1.1: User can log in with valid email and password
Task 1.2: System rejects login with invalid email format
Task 1.3: System locks account after 3 failed login attempts

Step 2: Work on one task at a time

Follow the green-red-green-green-green flow:

  1. 🟢 Start with tests passing
  2. 🔴 Write a failing test
  3. 🟢 Implement to make tests pass
  4. 🟢 Apply formatting while keeping tests green
  5. 🟢 Conduct review and apply changes while ensuring tests pass

🟢 Step 3: Ensure tests are green before proceeding

Never proceed with failing tests. Fix failures immediately.

🔴 Step 4: Write failing test first

Write a test that fails because the functionality doesn't exist yet. The failure should be due to missing functionality, not syntax errors.

🟢 Step 5: Write minimum implementation

Implement only enough code to make the current test pass. Avoid implementing features not yet tested.

🟢 Step 6: Apply formatting while keeping tests green

Apply all project formatting guidelines. Run tests after each formatting change.

🟢 Step 7: Conduct review after implementation

Review with user, demonstrate functionality, incorporate feedback.

Critical Rules

  • Never ignore failing tests
  • Never commit with failing tests
  • All tests pass before moving to next task

Verification Checks

Process Verification

  • Task list exists and is followed sequentially
  • Each task is a test before implementation
  • All tests pass before moving to next task
  • Code follows project formatting standards

Test Quality

  • Tests fail initially due to missing functionality
  • Test names clearly describe expected behavior
  • Tests use realistic data and scenarios
  • Full test suite runs successfully

Implementation Quality

  • Code implements only what tests require
  • Implementation follows project conventions
  • No functionality exists without corresponding tests
  • Reviews include test demonstrations

Per-Step Checks

Step 1: Tasks

  • Each task describes one externally observable behavior
  • Tasks use concrete language
  • Task list covers all requirements
  • Tasks ordered by priority or dependency

Step 2: Single Task Focus

  • Only one task is active at any time
  • No implementation extends beyond current task scope
  • Progress through task list is clearly documented

Step 3: Tests Green

  • All existing tests pass before starting new work
  • Never skip tests or run only some tests

Step 4: Failing Test

  • Test fails when first written
  • Failure is due to missing functionality

Step 5: Implementation

  • Implementation makes current test pass
  • No functionality beyond test requirements

Step 6: Formatting

  • All formatting rules applied
  • Tests remain green after formatting

Step 7: Review

  • Review includes running all tests
  • Feedback incorporated through test-first approach