skills/ar4mirez/samuel/testing-strategy

testing-strategy

SKILL.md

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

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:

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:

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:

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

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

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

  • 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

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

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

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

# 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
Weekly Installs
9
Repository
ar4mirez/samuel
GitHub Stars
3
First Seen
Feb 20, 2026
Installed on
opencode9
gemini-cli9
github-copilot9
codex9
amp9
kimi-cli9