/testing-strategy

name: testing-strategy
description: "Test pyramid, coverage targets, and unit/integration/E2E patterns. TRIGGER when: planning tests, writing test code, or reviewing coverage. SKIP: quality-gate scoring of plans (use quality-validation); root-causing a failing test (use systematic-debugging); proving a fix works (use verification-before-completion)."

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

---

TDD Enforcement (Red -> Green -> Refactor)

For new behavior and bug fixes, the failing test comes **first**. No production code without a test that demanded it.

| Step | Do | Gate | |------|----|------| | 1. Red | Write one small test for the next behavior; run it | It **fails for the expected reason** (not a typo/import error) | | 2. Green | Write the least code that passes | All tests pass; no extra behavior | | 3. Refactor | Clean names, duplication, structure | Tests stay green; no new behavior |

Rules:

• Never skip the red run - a test that never failed proves nothing.
• One behavior per cycle; commit-sized steps, not feature-sized.
• Bug fix = reproduce with a failing test first, then fix (see `systematic-debugging` for root-causing).
• Code written before its test: delete it and restart from red, or add the test and confirm it fails when the code is reverted.
• Legitimate exceptions (UI layout, throwaway spikes, generated code): say so explicitly rather than silently skipping.

Evidence of compliance in a report: the failing test output, then the passing output. Proving the final result is `verification-before-completion`'s job.

---

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 | Expecte