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 workflow instead)
- Reviewing test code quality (use
code-review skill)
- Validating CI pipeline configuration (use
Agent(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
- Test behavior, not implementation — assert outcomes, not internal calls
- One assertion per concept — each test verifies one logical thing
- Arrange-Act-Assert — clear structure in every test
- Deterministic — no flaky tests. Mock time, randomness, external services
- Independent — tests must not depend on execution order
- Descriptive names — test name describes the scenario:
should_return_404_when_user_not_found
- 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. Scaffolded by /ai-skills-init (per detected stack) and authored using Agent(qa-engineer). Always read TESTING.md before writing or running tests.
Integration
- Follows rules:
Agent(qa-engineer) (test strategy, automation, local test infra), Agent(software-engineer) (code quality)
- Used by workflows:
/test-local (full local QA cycle), /run-tests (lightweight execution), /ai-skills-init (TESTING.md scaffold), /develop, /feature-dev (single-agent fallback), /bugfix, /pre-commit
- Companion resources:
test-writing-guide.md
- Project context:
TESTING.md (root + per-service)
1---2name: test-strategy3description: Use this skill when writing tests, designing test plans, setting up test infrastructure, or evaluating test quality — test strategy design, a test writing guide, and coverage targets, providing patterns for unit, integration, E2E, and API testing.4---56<!-- ARCHITECTURAL NOTE: intentional model-invocable companion — deliberately no `context: fork` and no `disable-model-invocation`. Test-design knowledge skill applied by QA and `/run-tests`; it must stay model-invocable and composable into the caller's thread (not forked, not knowledge-only). Not a defect — do not reclassify. -->78# Testing Procedures910Systematic testing skill covering strategy, patterns, and quality gates. Produces consistent, maintainable test suites across tech stacks.1112## When to Use1314- Writing new tests for features or bug fixes15- Designing test strategy for a new project or module16- Evaluating existing test coverage and quality17- Setting up test infrastructure (fixtures, factories, mocks)18- Creating or updating `TESTING.md` documentation1920## When NOT to Use2122- Running tests (use `/run-tests` workflow instead)23- Reviewing test code quality (use `code-review` skill)24- Validating CI pipeline configuration (use `Agent(devops-engineer)` role)2526## Test Pyramid2728Follow the test pyramid for cost-effective coverage:2930```31 / E2E \ Few — critical user journeys only32 /----------\33 / Integration \ Moderate — API, DB, service boundaries34 /----------------\35 / Unit Tests \ Many — fast, isolated, comprehensive36 /--------------------\37```3839| Layer | What to Test | Speed | Count |40|---|---|---|---|41| **Unit** | Pure logic, transformations, validators, utils | < 50ms | Many |42| **Integration** | DB queries, API endpoints, service interactions | < 5s | Moderate |43| **E2E** | Critical user journeys, happy paths, key flows | < 30s | Few |4445## Test Design Principles46471. **Test behavior, not implementation** — assert outcomes, not internal calls482. **One assertion per concept** — each test verifies one logical thing493. **Arrange-Act-Assert** — clear structure in every test504. **Deterministic** — no flaky tests. Mock time, randomness, external services515. **Independent** — tests must not depend on execution order526. **Descriptive names** — test name describes the scenario: `should_return_404_when_user_not_found`537. **Fast feedback** — unit tests run in seconds, not minutes5455## Coverage Targets5657| Metric | Target | Hard Minimum |58|---|---|---|59| Line coverage | ≥ 80% | ≥ 60% |60| Branch coverage | ≥ 75% | ≥ 50% |61| Critical path coverage | 100% | 100% |62| New code coverage | ≥ 90% | ≥ 80% |6364**Critical paths** = authentication, authorization, payment, data mutations, error handling.6566## Key Context File6768Projects should have a `TESTING.md` at the root (and per-service in monorepos) documenting test infrastructure, commands, credentials, and organization. Scaffolded by `/ai-skills-init` (per detected stack) and authored using `Agent(qa-engineer)`. Always read `TESTING.md` before writing or running tests.6970## Integration7172- **Follows rules**: `Agent(qa-engineer)` (test strategy, automation, local test infra), `Agent(software-engineer)` (code quality)73- **Used by workflows**: `/test-local` (full local QA cycle), `/run-tests` (lightweight execution), `/ai-skills-init` (TESTING.md scaffold), `/develop`, `/feature-dev` (single-agent fallback), `/bugfix`, `/pre-commit`74- **Companion resources**: `test-writing-guide.md`75- **Project context**: `TESTING.md` (root + per-service)
avav25