Ar4mirez Samuel Testing Strategy

Testing Strategy

Systematic test planning and coverage improvement workflow.

When to Use

Coverage Targets

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

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):

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

Python (pytest):

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

Go:

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

Rust:

cargo tarpaulin --out Html

1.2 Analyze Coverage Gaps

Review coverage report for:

1.3 Identify Uncovered Files

List files with lowest coverage:

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:

2.2 Map Critical Files

For each critical path, list involved files:

Authentication Path:

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

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

         /\
        /  \
       / 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:

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

4.2 Effort Estimation

4.3 Prioritized Test Backlog

## 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:

5.2 Edge Case Checklist

For each function:

• Happy path tested
• Null input tested
• Undefined input tested
• Empty input tested
• Minimum boundary tested
• Maximum boundary tested
• Invalid type tested
• Error conditions tested

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

Phase 7: Implementation Roadmap

7.1 Sprint Planning Template

## 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:

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:

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:

Quick Reference

Coverage Commands

# 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:

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

Integration Test:

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

Converted and distributed by TomeVault — claim your Tome and manage your conversions.