Test Driven Development

---
name: team-shinchan:test-driven-development
description: Use when writing new code or fixing bugs during Stage 3 execution. Enforces RED-GREEN-REFACTOR cycle.
user-invocable: false
---

# TDD Enforcement: RED-GREEN-REFACTOR

## The Iron Law

**No production code without a failing test first.**

Every line of production code must be justified by a test that failed without it. No exceptions unless explicitly approved by a human.

## The Cycle

### 1. RED -- Write a Failing Test

Write a test for the behavior you need. Run it. **It MUST fail.** If it passes, your test is wrong or the behavior already exists.

```
verify-RED: Run test → confirm FAIL
If test passes → STOP. Investigate why.
```

### 2. GREEN -- Write Minimal Code

Write the **minimum** production code to make the test pass. Nothing more.

```
verify-GREEN: Run test → confirm PASS
If test fails → fix production code (not the test)
```

### 3. REFACTOR -- Clean Up

Improve code structure while keeping tests green. Run tests after every change.

## Rationalization Table

Do NOT skip TDD. Every excuse has a counter:

| Excuse | Counter |
|--------|---------|
| "It's too simple to test" | Simple code has simple tests. Write it in 30 seconds. |
| "I'll add tests after" | You won't. And if you do, they'll test your implementation, not your intent. |
| "This is just a config change" | Config changes break things. Write a test that loads the config. |
| "Tests will slow me down" | Debugging without tests is slower. TDD prevents 80% of debugging. |
| "I need to prototype first" | Prototypes become production. Start with a test or get explicit human approval to skip. |
| "The existing code has no tests" | Add a test for the behavior you're changing. Don't perpetuate the gap. |
| "It's a one-line fix" | One-line fixes cause production outages. A one-line test prevents them. |

## Testing Anti-Patterns

- **Shotgun debugging**: Trying random fixes without understanding the failure. Write a failing test first.
- **Test-after rationalization**: "I'll test it later" is never later. Test first or never.
- **Mocking everything**: If you mock the world, you test nothing. Mock boundaries, not internals.
- **Testing implementation details**: Test behavior (what), not implementation (how). Tests should survive refactoring.

## Exceptions

TDD may be skipped ONLY with **explicit human approval** for:
- Throwaway prototypes (marked as such, with a plan to rewrite with TDD)
- Pure documentation or configuration with no behavioral impact

If in doubt, write the test. It takes less time than debating whether to skip it.