testing-strategy

name	testing-strategy
description	Test pyramid, coverage targets, and test patterns (unit/integration/E2E). TRIGGER when: planning tests, writing test code, or reviewing coverage. SKIP: quality-gate scoring of plans (use quality-validation); security testing (use security-review-checklists). (Examples use common runners such as pytest and vitest.)

Testing Strategy Skill

Purpose

Comprehensive testing guidelines including test pyramid, coverage targets, and test patterns.

Auto-Invoke Triggers

• Planning test strategy
• Writing unit/integration tests
• Reviewing test coverage
• Setting up test infrastructure

---

Test Pyramid

        /\
       /  \      E2E Tests (10%)
      /----\     - Critical user flows
     /      \    - Slow, expensive
    /--------\   Integration Tests (20%)
   /          \  - API tests, DB tests
  /------------\ - Medium speed
 /              \ Unit Tests (70%)
/----------------\ - Fast, isolated
                   - Business logic

Distribution Guidelines

Type	Percentage	Focus
Unit	70%	Business logic, utilities
Integration	20%	API, database, services
E2E	10%	Critical user journeys

---

Coverage Targets

Metric	Minimum	Target
Line coverage	70%	80%
Branch coverage	60%	70%
Critical paths	90%	100%

What to Cover

• All public methods
• Business logic
• Edge cases
• Error handling
• Integration points

What NOT to Cover

• Generated code
• Simple getters/setters
• Framework code
• Third-party libraries

---

Unit Testing

Principles

• Test one thing per test
• Tests should be fast (< 100ms)
• Tests should be isolated
• Tests should be deterministic
• No external dependencies

AAA Pattern

Arrange - Set up test data and mocks
Act     - Execute the method under test
Assert  - Verify the expected outcome

Naming Convention

{Method}_{Scenario}_{ExpectedResult}

CreateUser_ValidData_ReturnsUserId
CreateUser_DuplicateEmail_ThrowsConflict
CalculateTotal_EmptyCart_ReturnsZero

Test Categories

Category	Purpose	Example
Happy path	Normal operation	Valid user creation
Edge case	Boundary conditions	Empty input, max length
Error case	Failure scenarios	Invalid data, not found

---

Integration Testing

Scope

• API endpoints
• Database operations
• External service calls
• Message queues

Best Practices

• Use test containers or in-memory DB
• Seed known test data
• Clean up after each test
• Mock external services
• Test full request/response cycle

API Test Checklist

• Correct status code
• Response body structure
• Headers (content-type, auth)
• Validation errors
• Authorization rules

---

E2E Testing

When to Use

• Critical user journeys
• Payment flows
• Authentication flows
• Multi-step workflows

Best Practices

• Test user perspective, not implementation
• Use stable selectors (data-testid)
• Handle async operations properly
• Keep tests independent
• Use page object pattern

Critical Paths to Test

• User registration/login
• Main feature workflow
• Payment/checkout
• Error recovery flows

---

Test Data Management

Strategies

Strategy	Use Case
Fixtures	Static test data
Factories	Dynamic test data
Builders	Complex objects
Seeders	Database state

Rules

• Use realistic but fake data
• Never use production data
• Reset state between tests
• Use faker libraries for variety

---

Mocking Guidelines

When to Mock

• External services (APIs, databases)
• Time-dependent operations
• Random values
• Expensive operations

When NOT to Mock

• Simple value objects
• The code under test
• Everything (over-mocking)

Mock Types

Type	Purpose
Stub	Return canned responses
Mock	Verify interactions
Spy	Record calls, pass through
Fake	Simplified implementation

---

Test Organization

File Structure

tests/
├── unit/
│   ├── services/
│   └── utils/
├── integration/
│   ├── api/
│   └── db/
├── e2e/
├── fixtures/
└── conftest.py / setup.ts

Naming

• Test files: {module}_test.py or {module}.test.ts
• Match source structure
• Group related tests in describe/class

---

CI/CD Integration

Pipeline Stages

1. Unit tests - Run on every commit
2. Integration tests - Run on PR/merge
3. E2E tests - Run on deploy to staging

Quality Gates

Gate	Requirement
Unit tests	100% pass
Coverage	> 70%
Integration	100% pass
E2E (critical)	100% pass

---

Performance Testing

Types

Type	Purpose
Load	Expected traffic
Stress	Breaking point
Soak	Memory leaks
Spike	Sudden traffic

Metrics to Measure

• Response time (p50, p95, p99)
• Throughput (requests/second)
• Error rate
• Resource usage

---

Best Practices

DO

• Write tests before fixing bugs
• Test behavior, not implementation
• Keep tests simple and readable
• Run tests frequently
• Maintain test code quality
• Use meaningful assertions

DON'T

• Test private methods directly
• Write flaky tests
• Skip tests temporarily (delete instead)
• Test external systems
• Ignore slow tests
• Copy-paste test code

---

Test Quality Checklist

• Tests are fast (< 10s for unit suite)
• Tests are isolated (no order dependency)
• Tests are deterministic (no flakiness)
• Tests are readable (clear intent)
• Tests cover edge cases
• Tests verify error handling
• Mocks are minimal and purposeful
• CI runs tests automatically