test-driven-development

# Test-Driven Development

Write tests first, then implementation. No production code without a failing
test.

## Purpose

TDD ensures code correctness through disciplined test-first development. Tests
written after implementation prove nothing - they pass immediately, providing
no evidence the code works correctly. This skill enforces the RED-GREEN-REFACTOR
cycle as a non-negotiable practice.

## The Iron Law

**NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.**

If you write code before the test, you must delete it and start over. The test
drives the implementation, not the other way around.

## The Cycle

### RED: Write a Failing Test

Write ONE minimal test that demonstrates the required behavior:

1. Test the public interface, not internals
2. Use real code, not mocks (unless crossing boundaries)
3. Name the test to describe the behavior
4. Run the test - it MUST fail

**Mandatory verification:**

```text
Run the test. Confirm it fails for the RIGHT reason:
- Missing function/method (expected)
- Wrong return value (expected)
- NOT: Syntax error
- NOT: Import error
- NOT: Test framework misconfiguration
```

If the test passes immediately, you've written it wrong or the feature already
exists. Investigate before proceeding.

### GREEN: Write Minimal Code

Write the SIMPLEST code that makes the test pass:

1. No extra features
2. No premature optimization
3. No "while I'm here" additions
4. Just enough to satisfy the test

**Mandatory verification:**

```text
Run the test. Confirm:
- The new test passes
- All other tests still pass
- No new warnings or errors
```

### REFACTOR: Improve Without Breaking

Improve code quality while keeping tests green:

1. Remove duplication
2. Improve names
3. Extract helpers
4. Simplify logic

**After each change:**

```text
Run all tests. They must still pass.
If any test fails, revert the refactor.
```

## Cycle Example

```text
Requirement: Function that validates email addresses

RED:
  Write test: expect(isValidEmail("user@e