Testing Pyramid Reference

Target Agents

• manager-develop - Primary: applies patterns during test creation and coverage analysis
• manager-develop - Secondary: applies during RED-GREEN-REFACTOR cycles

Test Pyramid Ratios

/  E2E  \        10% — Critical user journeys only
      /----------\
     / Integration \    20% — API endpoints, DB queries, service boundaries
    /----------------\
   /    Unit Tests    \  70% — Functions, hooks, utilities, pure logic
  /--------------------\

Coverage Targets by Context

Test Pattern: AAA (Arrange-Act-Assert)

// Arrange: Set up test data and preconditions
input := CreateTestUser("test@example.com")

// Act: Execute the function under test
result, err := service.CreateUser(ctx, input)

// Assert: Verify the outcome
assert.NoError(t, err)
assert.Equal(t, "test@example.com", result.Email)

Unit Test Patterns

Integration Test Patterns

What to Test vs What NOT to Test

ALWAYS Test

• Business logic and calculations
• Input validation and error handling
• Authentication and authorization flows
• Data transformations and mappings
• Edge cases and boundary conditions
• Race conditions (with -race flag in Go)

NEVER Test

• Framework internals (React rendering, Express routing)
• Third-party library behavior
• Simple getters/setters with no logic
• Private methods directly (test via public API)
• Generated code (protobuf, swagger)
• CSS styling and layout (use visual regression tools instead)

Test Quality Metrics

Test File Conventions

TDD RED-GREEN-REFACTOR Quick Reference

RED:     Write a failing test that defines expected behavior
GREEN:   Write minimal code to make the test pass
REFACTOR: Clean up while keeping tests green

Rules:

• Never write production code without a failing test
• Write the smallest test that fails
• Write the simplest code that passes
• Refactor only when all tests are green
• One assertion per test (when practical)

Common Rationalizations

DAMP over DRY: Test code should be descriptive and self-contained. A reader should understand the test without reading shared fixtures or helper methods.

Red Flags

• Test pyramid inverted: more E2E tests than unit tests
• Unit tests depend on external services (databases, APIs, file systems)
• Test assertions check implementation details instead of behavior
• No integration tests between unit and E2E layers
• Flaky test present without a quarantine label or tracking issue

Verification

• Test distribution follows the pyramid: unit > integration > E2E (show test counts per category)
• Unit tests run in under 30 seconds total
• Integration tests mock external dependencies at the boundary
• No flaky tests in the active suite (run 3x to verify stability)
• Test names describe behavior, not implementation (review naming convention)
• Coverage report shows meaningful assertions, not just line execution