swissarmyhammer/tdd

Test-Driven Development (TDD)

Overview

Write the test first. Watch it fail. Write correct, well-designed code to pass.

Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.

Take your time and do your best work. There is no reward for speed. There is every reward for correctness.

Violating the letter of the rules is violating the spirit of the rules.

When to Use

Always:

• All code changes, no exceptions
• If it is worth coding, it is worth testing

Thinking "skip TDD just this once"? Stop. That's rationalization.

The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Did you write code before the test? Delete it. Start over.

No exceptions:

• Don't keep it as "reference"
• Don't "adapt" it while writing tests
• Don't look at it
• Delete means delete

Red-Green-Refactor

RED — Write Failing Test

Write one minimal test showing what should happen.

Requirements:

• One behavior per test
• Clear descriptive name — "and" in name? Split it
• Real code, not mocks (unless unavoidable)
• Shows intended API usage

Verify RED — Watch It Fail

MANDATORY. Never skip.

Run the test. Confirm:

• Test fails (not errors, not compilation failures)
• Failure message matches expectation
• Fails because the feature is missing, not because of typos

Test passes immediately? You're testing existing behavior. Fix the test.

Test errors? Fix the error, re-run until it fails correctly.

GREEN — Correct Code

Write correct, well-designed code that passes the test and follows the codebase's prevailing patterns.

• Don't add features beyond what the test requires
• Don't refactor unrelated code in this step — that's what REFACTOR is for
• Match the style, idioms, and conventions already established in the codebase

Verify GREEN — Watch It Pass

MANDATORY.

Run the test. Confirm:

• New test passes
• All other tests still pass
• Output is pristine — no errors, no warnings

New test fails? Fix the code, not the test.

Other tests broke? Fix them now.

REFACTOR — Clean Up

Only after green — this is where you make the code excellent:

• Remove duplication
• Improve names and clarity
• Extract helpers that follow existing patterns
• Ensure the solution is robust, idiomatic, and the best version of itself

Keep tests green throughout. Don't add new behavior, but do make the existing behavior bulletproof.

Repeat

Next failing test for the next behavior.

Common Rationalizations

| Excuse | Reality | |--------|---------| | "Too simple to test" | Simple code breaks. Test takes 30 seconds. | | "I'll test after" | Tests passing immediately prove nothing. | | "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" | | "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. | | "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. | | "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. | | "Need to explore first" | Fine. Throw away exploration, start with TDD. | | "Test hard = design unclear" | Listen to the test. Hard to test = hard to use. | | "TDD will slow me down" | TDD is faster than debugging. Pragmatic = test-first. | | "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. | | "Existing code has no tests" | You're improving it. Add tests for the code you touch. |

Red Flags — STOP and Start Over

• Code written before test
• Test written after implementation
• Test passes immediately on first run
• Can't explain why the test failed
• Tests added "later"
• Rationalizing "just this once"
• "I already manually tested it"
• "Tests after achieve the same purpose"
• "It's about spirit not ritual"
• "Keep as reference" or "adapt existing code"
• "Already spent X hours, deleting is wasteful"
• "TDD is dogmatic, I'm being pragmatic"
• "This is different because..."

All of these mean: Delete the code. Start over with TDD.

Why Order Matters

"I'll write tests after to verify it works"

Tests written after code pass immediately. Passing immediately proves nothing:

• Might test the wrong thing
• Might test implementation, not behavior
• Might miss edge cases you forgot
• You never saw it catch the bug

Test-first forces you to see the test fail, proving it actually tests something.

"Deleting X hours of work is wasteful"

Sunk cost fallacy. The time is already gone. Your choice now:

• Delete and rewrite with TDD (more hours, high confidence)
• Keep it and add tests after (30 min, low confidence, likely bugs)

The "waste" is keeping code you can't trust.

"TDD is dogmatic, being pragmatic means adapting"

TDD IS pragmatic:

• Finds bugs before commit (faster than debugging after)
• Prevents regressions (tests catch breaks immediately)
• Documents behavior (tests show how to use code)
• Enables refactoring (change freely, tests catch breaks)

"Pragmatic" shortcuts = debugging in production = slower.

Good Tests

| Quality | Good | Bad | |---------|------|-----| | Minimal | One thing. "and" in name? Split it. | test('validates email and domain and whitespace') | | Clear | Name describes behavior | test('test1') | | Shows intent | Demonstrates desired API | Obscures what code should do | | Real code | Tests actual behavior | Tests mock behavior |

When Stuck

| Problem | Solution | |---------|----------| | Don't know how to test | Write the wished-for API. Write the assertion first. Ask the user. | | Test too complicated | Design too complicated. Simplify the interface. | | Must mock everything | Code too coupled. Use dependency injection. | | Test setup huge | Extract helpers. Still complex? Simplify design. |

Debugging Integration

Bug found? Write a failing test that reproduces it. Follow the TDD cycle. The test proves the fix and prevents regression.

Never fix bugs without a test.

Verification Checklist

Before marking work complete:

• [ ] Every new function/method has a test
• [ ] Watched each test fail before implementing
• [ ] Each test failed for the expected reason (feature missing, not typo)
• [ ] Wrote correct, well-designed code to pass each test
• [ ] All tests pass
• [ ] Output pristine (no errors, no warnings)
• [ ] Tests use real code (mocks only if unavoidable)
• [ ] Edge cases and errors covered

Can't check all boxes? You skipped TDD. Start over.

Final Rule

Production code → test exists and failed first
Otherwise → not TDD

No exceptions without the user's explicit permission.