Testing Strategy

Systematic test planning and coverage improvement workflow.

When to Use

Trigger	Description
Post-COMPLEX Feature	After implementing major features
Coverage Drop	When coverage falls below thresholds
Test Debt Sprint	Dedicated testing improvement effort
New Project	Establishing testing foundation
Pre-Release	Ensuring quality before deployment

Coverage Targets

Category	Target	Warning	Critical
Business Logic	>80%	70-80%	<70%
Overall	>60%	50-60%	<50%
Critical Paths	>90%	80-90%	<80%

Prerequisites

Before starting:

• Test framework configured
• Coverage tool available
• CI/CD running tests
• Access to current coverage report
• Understanding of business-critical features

Strategy Process

code

Phase 1: Coverage Analysis
    ↓
Phase 2: Critical Path Identification
    ↓
Phase 3: Test Pyramid Planning
    ↓
Phase 4: Test Prioritization
    ↓
Phase 5: Edge Case Planning
    ↓
Phase 6: Flaky Test Remediation
    ↓
Phase 7: Implementation Roadmap

Phase 1: Coverage Analysis

1.1 Generate Coverage Report

Node.js (Jest/Vitest):

bash

npm test -- --coverage
# or
npx vitest run --coverage

Python (pytest):

bash

pytest --cov=src --cov-report=html

Go:

bash

go test -cover ./...
go test -coverprofile=coverage.out ./...
go tool cover -html=coverage.out

Rust:

bash

cargo tarpaulin --out Html

1.2 Analyze Coverage Gaps

Review coverage report for:

Area	Target	Current	Gap
`src/auth/`	90%	45%	-45%
`src/api/`	80%	62%	-18%
`src/utils/`	60%	78%	+18%
Overall	60%	55%	-5%

1.3 Identify Uncovered Files

List files with lowest coverage:

code

Lowest Coverage Files:
1. src/auth/oauth.ts - 12% (critical!)
2. src/api/payments.ts - 28% (critical!)
3. src/services/email.ts - 35%
4. src/utils/validation.ts - 42%
5. src/api/users.ts - 48%

Phase 2: Critical Path Identification

2.1 Define Critical Paths

Critical paths are user journeys that MUST work:

Path	Description	Files	Priority
Authentication	Login, logout, session	auth/*	P0
Checkout	Cart → Payment → Confirm	payments/, cart/	P0
Registration	Signup → Verify → Profile	users/, email/	P1
Search	Query → Results → Filter	search/, api/	P1

2.2 Map Critical Files

For each critical path, list involved files:

Authentication Path:

code

src/auth/login.ts        - 45% coverage
src/auth/session.ts      - 52% coverage
src/auth/middleware.ts   - 88% coverage
src/models/user.ts       - 72% coverage

2.3 Calculate Critical Path Coverage

code

Authentication Path:
- Total lines: 450
- Covered lines: 267
- Coverage: 59% (target: 90%)
- Gap: 183 lines to cover

Phase 3: Test Pyramid Planning

3.1 Ideal Test Pyramid

code

         /\
        /  \
       / E2E \         10% - Slow, expensive, covers user flows
      /______\
     /        \
    /Integration\      20% - Medium speed, covers integrations
   /______________\
  /                \
 /    Unit Tests    \  70% - Fast, cheap, covers logic
/____________________\

3.2 Current Distribution

Analyze current test distribution:

code

Current State:
- Unit tests: 45 (60%)
- Integration: 25 (33%)
- E2E: 5 (7%)

Ideal State:
- Unit tests: 70 (70%)
- Integration: 20 (20%)
- E2E: 10 (10%)

Gap:
- Need +25 unit tests
- Need -5 integration tests (or OK)
- Need +5 E2E tests

3.3 Test Type Guidelines

Unit Tests (70%):

•Pure functions
•Business logic
•Utility functions
•Model methods
•State transitions

Integration Tests (20%):

•API endpoints
•Database operations
•Service interactions
•Authentication flows
•External service mocks

E2E Tests (10%):

•Critical user journeys
•Happy path scenarios
•Cross-system flows
•Smoke tests

Phase 4: Test Prioritization

4.1 Priority Matrix

Priority	Criteria	Example
P0	Critical path, no tests	Payment processing
P1	Critical path, low coverage	Authentication
P2	High risk, medium coverage	Data validation
P3	Medium risk, any coverage	Utility functions
P4	Low risk, nice to have	Formatting helpers

4.2 Effort Estimation

Test Type	Effort	Coverage Impact
Unit (simple)	15 min	High
Unit (complex)	1 hour	High
Integration	2 hours	Medium
E2E	4 hours	Low (but valuable)

4.3 Prioritized Test Backlog

markdown

## Test Backlog

### P0 - Immediate (This Sprint)
- [ ] Unit: payment.processPayment()
- [ ] Unit: auth.validateToken()
- [ ] Integration: POST /api/payments
- [ ] E2E: Complete checkout flow

### P1 - High (Next Sprint)
- [ ] Unit: auth.refreshToken()
- [ ] Unit: user.validateEmail()
- [ ] Integration: GET /api/users/:id
- [ ] E2E: Registration flow

### P2 - Medium (Backlog)
- [ ] Unit: validation helpers
- [ ] Unit: formatting utilities
- [ ] Integration: Search API

### P3 - Low (Nice to Have)
- [ ] Unit: logging utilities
- [ ] Unit: config loaders

Phase 5: Edge Case Planning

5.1 Required Edge Cases

Every function should test:

Category	Cases	Example
Null/Undefined	null, undefined input	`validateUser(null)`
Empty	"", [], {}	`searchUsers("")`
Boundary	0, -1, MAX_INT	`setQuantity(0)`
Invalid Type	Wrong type input	`calculatePrice("abc")`
Concurrent	Race conditions	Parallel updates

5.2 Edge Case Checklist

For each function:

Phase 6: Flaky Test Remediation

6.1 Identify Flaky Tests

Signs of flaky tests:

•Intermittent failures in CI
•Tests that pass locally but fail in CI
•Tests that depend on execution order
•Tests with timing-dependent assertions

6.2 Common Causes & Fixes

Cause	Symptom	Fix
Timing	Random timeouts	Use proper async/await
Order dependency	Fails when run alone	Reset state in beforeEach
Shared state	Random failures	Isolate test data
External services	Network failures	Mock external calls
Date/time	Fails at midnight	Mock dates

Phase 7: Implementation Roadmap

7.1 Sprint Planning Template

markdown

## Sprint 1: Critical Path (2 weeks)

### Goals
- Achieve 90% coverage on authentication
- Achieve 90% coverage on payments
- Add 5 E2E tests for critical paths

### Tasks
1. Unit tests for auth module (20 tests)
2. Unit tests for payment module (15 tests)
3. Integration tests for auth API (5 tests)
4. E2E test: Complete checkout (1 test)
5. E2E test: Login flow (1 test)

### Expected Outcome
- Overall coverage: 55% → 65%
- Critical path coverage: 59% → 90%

7.2 Test Writing Guidelines

Test Structure:

typescript

describe('Module or Function', () => {
  // Setup
  beforeEach(() => {
    // Reset state
  });

  describe('method or scenario', () => {
    it('should [expected behavior] when [condition]', () => {
      // Arrange
      const input = createTestInput();

      // Act
      const result = functionUnderTest(input);

      // Assert
      expect(result).toEqual(expectedOutput);
    });
  });
});

Naming Convention:

code

should [expected behavior] when [condition]

Examples:
- should return user when valid ID provided
- should throw error when user not found
- should update timestamp when saving

7.3 Coverage Tracking

Track coverage weekly:

Week	Overall	Business	Critical	Tests Added
1	55%	62%	59%	+15
2	62%	75%	78%	+22
3	68%	82%	88%	+18
4	72%	85%	92%	+12

Quick Reference

Coverage Commands

bash

# Node.js
npm test -- --coverage --coverageReporters=text-summary

# Python
pytest --cov=src --cov-report=term-missing

# Go
go test -cover ./... | grep -E "coverage:"

# Rust
cargo tarpaulin --out Stdout

Test Templates

Unit Test:

typescript

describe('functionName', () => {
  it('should [behavior] when [condition]', () => {
    const result = functionName(input);
    expect(result).toEqual(expected);
  });
});

Integration Test:

typescript

describe('POST /api/resource', () => {
  it('should create resource when valid data', async () => {
    const response = await request(app)
      .post('/api/resource')
      .send(validData);
    expect(response.status).toBe(201);
  });
});

Checklist

Analysis

• Coverage report generated
• Gaps identified
• Critical paths mapped
• Current pyramid analyzed

Planning

• Tests prioritized
• Edge cases documented
• Flaky tests identified
• Sprint plan created

Implementation

• P0 tests written
• P1 tests written
• Edge cases covered
• Flaky tests fixed

Validation

• Coverage targets met
• All tests passing
• No flaky tests
• CI/CD updated

Extended Resources

For detailed examples, patterns, and in-depth guidance, see:

•references/process.md - Comprehensive testing patterns and examples

Related Resources

•code-review - Includes test validation
•refactoring - Tests enable safe refactoring
•troubleshooting - When tests fail unexpectedly