Testing Strategies: TDD Patterns and Test Automation with Claude Code#

Without tests:
  You → "implement rate limiting"
  Claude → writes code that looks correct
  You → manually test → find edge case
  You → "fix this edge case"
  Claude → patches it
  You → manually test → find another issue
  ... repeat

With tests:
  You → "write tests for rate limiting, then implement"
  Claude → writes tests → writes code → runs tests →
           sees failures → fixes → runs again → all pass
  You → review the final result

RED: Write failing tests
  Claude writes tests for functionality that
  doesn't exist yet. Tests should fail.
       │
GREEN: Implement to pass
  Claude writes the minimum code to make
  all tests pass. Nothing more.
       │
REFACTOR: Clean up with safety
  Claude improves the code while keeping
  all tests passing.
       │
  Commit and move to the next feature

Step 1: Write tests first
  "write tests for a rate limiter that allows 5
   requests per minute per IP address. cover:
   - allowing requests under the limit
   - rejecting requests over the limit (429 status)
   - resetting the counter after the time window
   - handling multiple IPs independently
   do NOT write any implementation yet"

Step 2: Confirm tests fail
  "run the tests to confirm they fail"

Step 3: Commit the failing tests
  "commit the tests with message: 'add rate limiter
   tests (red phase)'"

Step 4: Implement
  "implement the rate limiter with the sole goal
   of making all committed tests pass. run the tests
   after each change"

Step 5: Commit the passing implementation
  "commit the implementation"

Step 6: Refactor (optional)
  "refactor the rate limiter for clarity. keep all
   tests passing"

Explicit TDD prompt:
  "I'm doing TDD. Write tests FIRST for the feature
   described below. Do NOT create any implementation
   code, mocks, or stubs. The tests should fail when
   run against the current codebase."

Specify the framework:
  "write tests using go test with the testify assertion
   library, matching the patterns in existing test files"

Specify what to test:
  "write a test for the ParseConfig function covering:
   valid YAML input, missing required fields, invalid
   port numbers, and an empty file"

Specify what NOT to do:
  "do not use mocks for the database. use testcontainers
   for integration tests, matching the pattern in
   user_test.go"

Commit 1: "add rate limiter tests (red)"
  → Tests exist but fail. Requirements are captured.

Commit 2: "implement rate limiter (green)"
  → Tests pass. Minimum viable implementation.

Commit 3: "refactor rate limiter for clarity"
  → Code is clean. Tests still pass.

Same context (biased):
  Claude thinks about implementation → writes tests
  that match its planned approach → writes code that
  passes easily → edge cases get missed because the
  tests and code share assumptions

Separate contexts (unbiased):
  Session A writes tests based on requirements →
  Session B writes code to pass tests → mismatch
  between assumptions gets caught

Session A (test writer):
  "write comprehensive tests for user notification
   preferences. cover opt-in, opt-out, per-channel
   preferences, and bulk updates"
       │
  → Tests committed to git
       │
Session B (implementer):
  "run the tests in notification_test.go. implement
   whatever is needed to make them all pass"

"use a subagent to write tests for the checkout flow.
 the subagent should cover: adding items, removing
 items, applying discount codes, and calculating tax.
 once the tests are committed, I'll implement the code
 in the main session"

Step 1: Write a test specification
  "write a test plan for the search feature in
   TESTPLAN.md. list every test case with inputs
   and expected outputs, but don't write code yet"
       │
Step 2: /clear
       │
Step 3: Generate tests from the spec
  "read TESTPLAN.md and generate test code for
   every case listed. use the testing patterns
   from the existing test files"
       │
Step 4: Implement
  "make all tests pass"

"look at how tests are structured in user_test.go.
 follow the same patterns for the new auth tests:
 table-driven tests, testify assertions, test
 fixtures in testdata/"

Good: "use testcontainers for database tests, matching
      the pattern in user_test.go"

Good: "use httptest.NewServer to create a real HTTP
      server for API client tests"

Avoid: "mock the database interface and verify the
       query was called with the right parameters"
       (tests the mock, not the code)

Behavior test (durable):
  "test that a rate-limited request returns 429
   with a Retry-After header"

Implementation test (fragile):
  "test that the rate limiter increments the Redis
   counter and checks it against the threshold"

"write tests that verify the external behavior of the
 API -- inputs and outputs. don't test internal
 implementation details"

"after writing the main tests, add edge case tests for:
 - empty input
 - nil/null values
 - boundary values (0, max int, empty string)
 - concurrent access
 - error conditions (network timeout, permission denied)
 - Unicode and special characters in string inputs"

"review the tests you just wrote. what edge cases
 are missing? add them"

Context window fills up → compaction happens →
  conversation summary may lose details →
  BUT test files on disk are unchanged

Session ends → new session starts →
  conversation history is gone →
  BUT test files on disk are unchanged

Session 1: Write all the tests
  "write comprehensive tests for the notification
   system. commit them when done."
  → Tests committed to git

Session 2 (next day, fresh context):
  "run the tests in internal/notification/. implement
   whatever is needed to make them pass."
  → Claude discovers requirements from the tests

Session 3 (if needed):
  "continue making the notification tests pass.
   check which tests still fail and fix them."
  → Claude picks up where it left off

{
  "feature": "notification-system",
  "tests": [
    { "name": "create_notification", "status": "passing" },
    { "name": "email_delivery", "status": "passing" },
    { "name": "preference_opt_out", "status": "failing" },
    { "name": "bulk_notifications", "status": "not_started" },
    { "name": "rate_limiting", "status": "not_started" }
  ],
  "passing": 2,
  "failing": 1,
  "not_started": 2
}

"read tests.json, implement the next failing test
 case, run the tests, and update the status in
 tests.json when it passes"

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": "go test ./... 2>&1 | tail -20",
        "timeout": 30000
      }
    ]
  }
}

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": "golangci-lint run --new-from-rev=HEAD 2>&1 | head -20",
        "timeout": 15000
      }
    ]
  }
}

## Testing

- Run tests: go test ./...
- Run single test: go test -run TestName ./package/
- Integration tests: go test -tags=integration ./...
- Always run relevant tests after making changes
- Use testcontainers for database integration tests
- Use table-driven tests matching existing patterns
- Never delete a failing test -- fix the code or discuss

# Check test coverage for changed files
claude -p "analyze test coverage for files changed
in this PR. identify functions without tests and
suggest what test cases are needed" --output-format text

# Validate test quality
claude -p "review the tests in this PR. check for:
mock-heavy tests that don't test real behavior,
missing edge cases, and tests that would pass
even if the code was broken" --output-format text

# Generate tests for untested code in the PR
claude -p "find functions in the changed files
that lack tests. generate tests following the
patterns in existing test files. output only
the test code" --output-format text > new_tests.go

"find functions in the auth package that don't
 have corresponding tests. list them with a brief
 description of what each function does"

"run go test -coverprofile=coverage.out ./... and
 then go tool cover -func=coverage.out. show me
 functions with less than 50% coverage"

Step 1: Identify critical untested paths
  "which functions in the checkout package handle
   money or user data but don't have tests?"

Step 2: Write tests for the highest-risk code first
  "write tests for calculateTotal and processPayment.
   these handle money and need thorough testing"

Step 3: Run and verify
  "run the new tests and fix any failures in the
   tests (not the code -- the code is working in
   production)"

Coverage tells you:
  "this function has no tests at all"  ← useful
  "this function has 100% line coverage" ← doesn't
     mean the tests are good

Better quality signal:
  "do the tests verify the actual behavior?"
  "would the tests catch a real bug?"
  "do the tests cover edge cases?"

"review the tests for the auth package. for each
 test, evaluate: does it test real behavior or just
 implementation details? would it catch a real bug?
 what edge cases are missing?"

Bad:  mock.Expect("GetUser").Return(user)
      service.Process()
      mock.AssertCalled("GetUser")
      (tests that the mock was called, not that the code works)

Good: db := testcontainer.StartPostgres()
      db.Insert(testUser)
      result := service.Process()
      assert.Equal(expectedResult, result)
      (tests actual behavior with real dependencies)

Bad:  "this test keeps failing, delete it"
      (the test was probably right -- the code is broken)

Good: "this test is failing. is the test wrong or is
       the code wrong? investigate before changing either"

Bad:  "implement the feature" → "now write tests"
      (tests are biased toward what was just implemented)

Better: "write tests first" → "now implement"
      (tests define requirements, implementation follows)

Best: Session A writes tests → Session B implements
      (complete context isolation)

Bad:  "Claude hard-coded the expected API response in
       the test -- it matches the current output exactly
       but doesn't test the logic"

Good: "write tests that verify the structure and
       constraints of the response, not the exact values.
       a valid response has a non-empty 'id' field, a
       'created_at' timestamp in the past, and a 'status'
       that is one of: active, pending, disabled"

Bad:  "the tests pass" (didn't actually check)

Good: "run the tests with -v and show me the output.
       I want to see what's being tested"