Test Strategy

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)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: alex-voloshin-dev
• Source: alex-voloshin-dev/ai-skills
• License: MIT
• Homepage: https://voloshin.net

Install and usage instructions live in the source repository linked above.