Testing Strategy

Design comprehensive test strategies covering unit, integration, and end-to-end testing. Analyze coverage gaps, define test architecture, and create actionable test plans.

Workflow

Step 1: Understand the Testing Context

Gather information about what needs testing and the current state:

# Check existing test framework and config
cat jest.config.* vitest.config.* pytest.ini pyproject.toml 2>/dev/null | head -40

# Find existing tests
find . -name "*.test.*" -o -name "*.spec.*" -o -name "test_*" | grep -v node_modules | head -30

# Count test vs source files
echo "Source:" && find src -name "*.ts" -o -name "*.js" -o -name "*.py" 2>/dev/null | wc -l
echo "Tests:" && find . \( -name "*.test.*" -o -name "*.spec.*" -o -name "test_*" \) -not -path "*/node_modules/*" 2>/dev/null | wc -l

# Check for test scripts in package.json
grep -A5 '"scripts"' package.json 2>/dev/null | grep -i test

# Check coverage config
grep -r "coverage" jest.config.* vitest.config.* pyproject.toml 2>/dev/null

Identify:

• What test framework is in use?
• What test types exist (unit, integration, e2e)?
• What coverage exists and where are the gaps?
• What test utilities or fixtures are established?
• What CI integration exists for tests?

Step 2: Map the Testing Pyramid

Define what to test at each level based on the system's architecture:

Unit Tests (70% of tests)

• Pure functions and business logic.
• Data transformations and validations.
• State management logic.
• Utility functions and helpers.
• Individual class methods.

Characteristics: Fast (< 10ms each), isolated (no I/O), deterministic.

Integration Tests (20% of tests)

• API endpoint request-response cycles.
• Database operations (queries, transactions, migrations).
• Service-to-service communication.
• Message queue producers and consumers.
• Authentication and authorization flows.
• Third-party API integrations (with contract tests or sandboxes).

Characteristics: Use real databases (test containers), real HTTP, controlled test data.

End-to-End Tests (10% of tests)

• Critical user journeys (signup, purchase, core workflow).
• Cross-service flows that span multiple systems.
• Smoke tests for deployment verification.

Characteristics: Slow, brittle, expensive. Test only the most critical paths.

Step 3: Design the Test Strategy

For each component or feature, define:

What to test:

• Happy path: Does it work with valid input?
• Edge cases: Empty input, boundary values, maximum sizes.
• Error cases: Invalid input, missing dependencies, network failures.
• Security cases: Unauthorized access, injection, privilege escalation.
• Concurrency: Race conditions, duplicate submissions, stale data.

What NOT to test:

• Framework internals (don't test that React renders a div).
• Third-party library behavior (test your usage, not the library).
• Implementation details (test behavior, not how it's achieved).
• Trivial code (getters, setters, simple pass-through).

Mocking Strategy:

• Mock external services and APIs at the HTTP boundary.
• Mock the clock for time-dependent logic.
• Use real databases with test containers for integration tests.
• Avoid mocking internal modules — that couples tests to implementation.
• Use dependency injection to make mocking straightforward.

Step 4: Define Test Architecture

Establish patterns for the test suite:

Test Organization

src/
  services/
    order-service.ts
    order-service.test.ts          # Unit tests co-located
tests/
  integration/
    api/
      orders.test.ts               # Integration tests by feature
  e2e/
    checkout-flow.test.ts           # E2E tests by user journey
  fixtures/
    orders.ts                       # Shared test data
  helpers/
    test-db.ts                      # Test utilities
    api-client.ts

Test Data Management

• Use factories or builders for test data, not raw objects.
• Reset database state between tests (transactions or truncation).
• Avoid shared mutable state between tests.
• Use realistic but deterministic data (seeded random).

Test Utilities

• Create helpers for common setup (authenticated requests, seeded DB).
• Build custom matchers for domain-specific assertions.
• Standardize error assertion patterns.

Step 5: Create the Test Plan

Produce a concrete list of test cases organized by priority.

Output Format

Test Strategy Document

# Test Strategy: <Feature/Service Name>

## Overview
<What is being tested and why this strategy>

## Testing Pyramid

### Unit Tests
| Module/Function        | Test Cases                          | Priority |
|------------------------|-------------------------------------|----------|
| validateOrder()        | Valid order, empty items, negative qty | High   |
| calculateTotal()       | Normal, discounts, tax, rounding     | High     |
| formatCurrency()       | USD, EUR, zero, large numbers        | Medium   |

### Integration Tests
| Flow                   | Test Cases                          | Priority |
|------------------------|-------------------------------------|----------|
| POST /api/orders       | Create, validation error, auth, idempotency | High |
| Order + Payment        | Success, payment failure, retry      | High     |
| Order + Inventory      | In stock, out of stock, concurrent   | High     |

### End-to-End Tests
| Journey                | Steps                               | Priority |
|------------------------|-------------------------------------|----------|
| Checkout               | Browse -> Add to cart -> Pay -> Confirm | Critical |
| Returns                | Order history -> Request return -> Refund | High |

## Mocking Strategy

| Dependency            | Strategy                             |
|-----------------------|--------------------------------------|
| Payment API           | HTTP mock with recorded responses    |
| Database              | Test container with reset per test   |
| Email service         | In-memory spy                        |
| Clock/time            | Fake timers for expiration logic     |

## Test Data

| Entity  | Factory                   | Key Variants             |
|---------|---------------------------|--------------------------|
| User    | createTestUser(overrides)  | admin, customer, guest   |
| Order   | createTestOrder(overrides) | pending, paid, refunded  |
| Product | createTestProduct(overrides)| in-stock, discontinued  |

## Coverage Targets

| Layer        | Current | Target | Notes                       |
|--------------|---------|--------|-----------------------------|
| Unit         | 45%     | 80%    | Focus on business logic     |
| Integration  | 20%     | 60%    | API endpoints first         |
| E2E          | 5%      | N/A    | Critical paths only         |

## CI Integration

- Unit tests: run on every push (< 2 min)
- Integration tests: run on every PR (< 10 min)
- E2E tests: run before deploy to staging (< 20 min)

Specific Test Plan (for a single feature)

## Test Plan: <Feature Name>

### Unit Tests

#### Test: validateOrder rejects empty items
```<language>
test('rejects order with no items', () => {
  const result = validateOrder({ items: [] });
  expect(result.valid).toBe(false);
  expect(result.errors).toContain('Order must have at least one item');
});

Test: calculateTotal applies discount correctly

test('applies percentage discount', () => {
  const total = calculateTotal({
    items: [{ price: 1000, quantity: 2 }],
    discount: { type: 'percentage', value: 10 }
  });
  expect(total).toBe(1800);
});

Integration Tests

Test: POST /api/orders creates order successfully

...

## Examples

**User**: "How should we test the new payment integration?"
**Action**: Analyze the payment code, identify integration points (payment API, database, webhooks), and design a test strategy with unit tests for validation logic, integration tests for the API flow with mocked payment provider, and e2e tests for the critical checkout journey.

**User**: "We have low test coverage, where should we start?"
**Action**: Identify the highest-risk, least-tested code paths. Prioritize core business logic and critical API endpoints. Create a phased plan to improve coverage where it matters most.

**User**: "Write tests for this function" (with code)
**Action**: Analyze the function's inputs, outputs, and edge cases. Write concrete test cases covering happy path, error paths, and boundaries.

**User**: "Review our test suite"
**Action**: Read existing tests. Check for common anti-patterns (testing implementation, flaky tests, excessive mocking). Identify coverage gaps and suggest improvements.

## Best Practices

- Test behavior, not implementation. Tests should verify WHAT code does, not HOW it does it. This makes tests resilient to refactoring.
- The testing pyramid matters. Most tests should be fast unit tests. Integration and e2e tests should be targeted at high-risk flows. An inverted pyramid (mostly e2e) is slow, flaky, and expensive.
- Flaky tests are worse than no tests. They erode trust in the suite. Fix or remove them immediately.
- One assertion per test is a guideline, not a rule. A test should verify one BEHAVIOR, which may require multiple assertions.
- Test names should describe the scenario and expected outcome: "returns 404 when order does not exist" is good. "test1" is not.
- Use factories for test data, not copy-pasted objects. Factories make tests readable and maintainable.
- Avoid testing third-party code. Trust that the library works. Test YOUR usage of it.
- Mock at boundaries, not internally. Mock the HTTP client, not the service that uses it. This keeps tests realistic.
- Fast tests get run. Slow tests get skipped. Optimize for speed at every level.
- Coverage is a useful metric but a bad target. 100% coverage with bad tests gives false confidence. Focus on testing the right things well.