Testing Strategy

Testing Strategy

Purpose

Design comprehensive test strategies with test pyramid coverage, test file structure, and quality gates.

Inputs

• Feature description and scope
• Existing test infrastructure (framework, runner, coverage tools)
• CI/CD pipeline details (if relevant)
• Existing test conventions in the codebase
• Coverage targets or requirements (if any)

Process

Step 1: Audit Existing Test Infrastructure

• Test framework (Jest, Vitest, Playwright, Cypress, etc.)
• Test runner and configuration
• Coverage tools (Istanbul, c8, etc.)
• CI integration (GitHub Actions, etc.)
• Existing test patterns (file location, naming, describe/it structure)
• Existing mocking patterns (jest.mock, vi.mock, MSW, etc.)

Step 2: Identify Testable Units

From the feature, extract:

• Pure functions and utilities — deterministic, no side effects, easiest to test
• Data transformations — input/output mapping, validation logic
• API handlers/endpoints — request/response contracts, error handling
• UI components — render output, interaction behavior, state changes
• Integration points — database queries, external API calls, file I/O
• Business logic — rules, calculations, conditional flows

Step 3: Design the Test Pyramid

        /  E2E  \        ← Few: critical user paths only (expensive, slow)
       /----------\
      / Integration \    ← Some: cross-boundary, API contracts, DB queries
     /----------------\
    /    Unit Tests     \ ← Many: fast, isolated, 80%+ of test count
   /--------------------\

• Unit tests (base): Fast, isolated, test one thing. Target 80%+ of total test count.
• Integration tests (middle): Cross-boundary tests. Database interactions, API contracts, service-to-service.
• E2E tests (top): Critical user paths only. Expensive to write and maintain, keep count low.

Step 4: Write Test Specifications

For each layer, specify:

For each test case:

• Location: Follow existing convention (co-located __tests__/, top-level tests/, or .test.ts suffix)
• Description: describe('ModuleName', () => { it('should ...') }) format
• Key assertions: What exactly are we verifying?
• Mock strategy: What to mock (external deps), what to keep real (internal logic)
• Edge cases: Boundary values, empty inputs, error conditions

Step 5: Define Coverage Targets

• Line coverage: Pragmatic target (70-90%, not 100%)
• Branch coverage: Focus on critical paths and business logic branches
• Not worth testing: Glue code, framework boilerplate, simple pass-through, type-only files
• Must test: Business rules, data transformations, error handling, security-sensitive code

Step 6: Plan Quality Gates

• Pre-commit:
  • Lint (ESLint, Biome)
  • Type check (tsc --noEmit)
  • Affected unit tests (if tooling supports)
• CI pipeline:
  • Full test suite
  • Coverage threshold check
  • Build verification
• Manual review checklist:
  • New business logic has unit tests
  • Error paths are tested
  • No snapshot tests for logic (only for stable UI)
  • Mocks don't hide real bugs
  • Test descriptions read as documentation

Output Format

Test Pyramid Summary

Test Specifications

For each test file:

File: src/__tests__/feature.test.ts
Layer: Unit

describe('FeatureName')
  it('should handle the happy path')
    - Input: ...
    - Expected: ...
  it('should handle invalid input')
    - Input: ...
    - Expected: throws/returns error
  it('should handle edge case')
    - Input: ...
    - Expected: ...

Mocks: ExternalService (return mock data)

Coverage Targets

Quality Gate Checklist

• Pre-commit hooks configured
• CI runs full test suite
• Coverage thresholds enforced
• New code has corresponding tests

Quality Checks

• Every business logic function has a unit test spec
• Critical user paths have integration tests
• At least 1 E2E test for the main happy-path flow
• Mock strategy documented and doesn't hide real bugs
• Test file locations follow existing project conventions
• Edge cases and error paths included in test specs
• Coverage targets are pragmatic (not aspirational 100%)

Evolution Notes