# Test Strategy

> Test strategy design, test writing guide, and coverage targets. Use when writing tests, designing test plans, setting up test infrastructure, or evaluating test quality. Provides patterns for unit, integration, E2E, and API testing.

- Skill: `avav25/test-strategy-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add avav25/test-strategy-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/avav25/test-strategy-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: avav25 (https://skillmd.com/u/avav25)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/avav25/test-strategy-2

---


# Testing Procedures

Systematic testing skill covering strategy, patterns, and quality gates. Produces consistent, maintainable test suites across tech stacks.

## When to Use

- Writing new tests for features or bug fixes
- Designing test strategy for a new project or module
- Evaluating existing test coverage and quality
- Setting up test infrastructure (fixtures, factories, mocks)
- Creating or updating `TESTING.md` documentation

## When NOT to Use

- Running tests (use `run-tests` skill workflow instead)
- Reviewing test code quality (use `code-review` skill)
- Validating CI pipeline configuration (use `devops-engineer` role)

## Test Pyramid

Follow the test pyramid for cost-effective coverage:

```
        /  E2E  \           Few — critical user journeys only
       /----------\
      / Integration \       Moderate — API, DB, service boundaries
     /----------------\
    /    Unit Tests     \   Many — fast, isolated, comprehensive
   /--------------------\
```

| Layer | What to Test | Speed | Count |
|---|---|---|---|
| **Unit** | Pure logic, transformations, validators, utils | < 50ms | Many |
| **Integration** | DB queries, API endpoints, service interactions | < 5s | Moderate |
| **E2E** | Critical user journeys, happy paths, key flows | < 30s | Few |

## Test Design Principles

1. **Test behavior, not implementation** — assert outcomes, not internal calls
2. **One assertion per concept** — each test verifies one logical thing
3. **Arrange-Act-Assert** — clear structure in every test
4. **Deterministic** — no flaky tests. Mock time, randomness, external services
5. **Independent** — tests must not depend on execution order
6. **Descriptive names** — test name describes the scenario: `should_return_404_when_user_not_found`
7. **Fast feedback** — unit tests run in seconds, not minutes

## Coverage Targets

| Metric | Target | Hard Minimum |
|---|---|---|
| Line coverage | ≥ 80% | ≥ 60% |
| Branch coverage | ≥ 75% | ≥ 50% |
| Critical path coverage | 100% | 100% |
| New code coverage | ≥ 90% | ≥ 80% |

**Critical paths** = authentication, authorization, payment, data mutations, error handling.

## Key Context File

Projects should have a `TESTING.md` at the root (and per-service in monorepos) documenting test infrastructure, commands, credentials, and organization. Created by `project-init` skill using `qa-engineer` role. Always read `TESTING.md` before writing or running tests.

## Integration

- **Follows rules**: `qa-engineer` role (test strategy, automation, local test infra), `software-engineer` role (code quality)
- **Used by workflows**: `test-local` skill (full local QA cycle), `run-tests` skill (lightweight execution), `project-init` skill (TESTING.md generation), `feature-dev` skill, `bugfix` skill, `pre-commit` skill
- **Companion resources**: `test-writing-guide.md`
- **Template**: `templates/testing.template.md` (root + per-service TESTING.md templates)
- **Project context**: `TESTING.md` (root + per-service)