Testing Workflow

Orchestrate comprehensive testing across a project by coordinating the testing-patterns skill, e2e-testing skill, and testing agents. This meta-skill does not define test patterns itself — it routes to the right skill or agent at each stage and ensures nothing is missed.

---

When to Use

• Setting up testing for a new project from scratch
• Improving coverage for an existing project with gaps
• Establishing or revising a testing strategy
• Before a major release to verify quality gates are met
• After a large refactor to confirm nothing broke
• During code review when test adequacy is in question
• Onboarding a team to a testing workflow

---

Orchestration Flow

Follow these steps in order. Each step routes to a specific skill or agent — read and apply that resource before moving to the next step.

Phase 1: Discovery and Baseline

Scan the project to understand existing test infrastructure, measure current coverage, and identify gaps before making changes. Without a baseline, you cannot demonstrate improvement.

1. Identify test infrastructure — Determine the test runner, assertion library, coverage tool, and CI configuration already in use. If none exist, flag that setup is needed.
2. Measure current coverage — Run the existing test suite and record statement, branch, and function coverage. This is the baseline.
3. Map untested code — Identify modules, functions, and code paths with no test coverage. Prioritize by risk: business-critical logic first, utilities last.
4. Catalog existing tests — Categorize existing tests as unit, integration, or E2E. Check for skipped tests, flaky tests, and tests that don't assert anything meaningful.

Phase 2: Strategy Selection

Based on the discovery results, select the appropriate testing approach for this project.

1. Determine project type — Use the Coverage Targets table below to set appropriate thresholds for the project type.
2. Select test patterns — Read ai/skills/testing/testing-patterns/SKILL.md and choose the unit/integration test patterns that match the project's architecture, language, and framework.
3. Identify critical user journeys — List the 3-10 most important user workflows that require E2E coverage. These are flows where a failure would directly impact revenue, user trust, or safety.
4. Document the strategy — Fill in the Testing Strategy Template (below) and commit it to the repository.

Phase 3: Implementation

Generate tests following the patterns selected in Phase 2.

1. Unit tests first — Write unit tests for uncovered business logic, starting with the highest-risk modules. Follow the testing pyramid: ~70% of your tests should be unit tests.
2. Integration tests next — Write integration tests for module boundaries, API endpoints, and database queries. Focus on the seams where components interact.
3. E2E tests for critical journeys — Read ai/skills/testing/e2e-testing/SKILL.md and write E2E tests for each critical user journey identified in Phase 2.
4. Edge case coverage — After the happy paths are covered, add tests for error conditions, boundary values, null/empty inputs, and concurrency scenarios.

Phase 4: Validation

Verify that the new tests meet quality standards and coverage targets.

1. Run the full test suite — Every test must pass. Fix failures before proceeding.
2. Measure coverage against targets — Compare new coverage against the thresholds for the project type. If targets are not met, return to Phase 3.
3. Check test quality — Review tests for the anti-patterns listed in testing-patterns (assert-free tests, overmocking, flaky tests, test pollution). Fix any found.
4. Verify CI integration — Confirm that tests run automatically on every push/PR and that coverage thresholds are enforced in CI.

Phase 5: Maintenance

Establish ongoing practices to keep the test suite healthy.

1. Set up coverage ratcheting — Configure CI to fail if coverage drops below the current level. Coverage should only go up.
2. Establish flaky test policy — Any test that fails intermittently must be fixed within one sprint or removed with a justification.
3. Define test review standards — Every PR that adds or changes logic must include corresponding test changes. Reviewers check for this.
4. Schedule test health audits — Quarterly, review test execution time, flaky test rate, skipped test count, and coverage trends.

---

Skill Routing Table

Use this table to route specific needs to the correct resource:

| Need | Route To | Path |

|------|----------|------|

| Unit/integration test patterns | testing-patterns | ai/skills/testing/testing-patterns/SKILL.md |

| E2E test patterns | e2e-testing | ai/skills/testing/e2e-testing/SKILL.md |

| Code quality standards | clean-code | ai/skills/testing/clean-code/SKILL.md |

| Review checklist | code-review | ai/skills/testing/code-review/SKILL.md |

| CI/CD quality gates | quality-gates | ai/skills/testing/quality-gates/SKILL.md |

| Debugging test failures | debugging | ai/skills/testing/debugging/SKILL.md |

When a request falls clearly into one row, go directly to that resource. Use the full orchestration flow only when comprehensive coverage is the goal.

---

Coverage Targets

Targets vary by project type. Use the appropriate row to set expectations:

| Project Type | Statement | Branch | Function | E2E Journeys | Notes |

|--------------|-----------|--------|----------|--------------|-------|

| Startup MVP | 60% | 50% | 60% | Top 3 flows | Focus on critical paths only |

| Production App | 80% | 70% | 80% | Top 10 flows | Balance speed with confidence |

| Library / Package | 90% | 85% | 95% | N/A | Public API must be fully covered |

| Critical Infrastructure | 95% | 90% | 95% | All flows | Zero tolerance for gaps |

These are minimums. Aim higher when time permits, but do not block releases on vanity metrics — prioritize meaningful coverage over percentage points.

---

Testing Strategy Template

Use this template to document the testing strategy for a project. Fill it in during the orchestration flow and keep it in the repo.

# Testing Strategy

## Project Overview
- **Project**: [name]
- **Type**: [startup MVP | production app | library | critical infrastructure]
- **Primary Language**: [language]
- **Framework**: [framework]
- **Test Runner**: [runner]
- **Coverage Tool**: [tool]

## Coverage Baseline
- **Statement**: [X%]
- **Branch**: [X%]
- **Function**: [X%]
- **E2E Journeys Covered**: [N of M]
- **Date Measured**: [YYYY-MM-DD]

## Coverage Targets
- **Statement**: [target%]
- **Branch**: [target%]
- **Function**: [target%]
- **E2E Journeys**: [target count]

## Test Patterns Selected
- [ ] [Pattern 1 — reason for selection]
- [ ] [Pattern 2 — reason for selection]
- [ ] [Pattern 3 — reason for selection]

## Critical User Journeys (E2E)
1. [Journey 1 — e.g., signup -> onboarding -> first action]
2. [Journey 2 — e.g., login -> dashboard -> export]
3. [Journey 3 — e.g., checkout -> payment -> confirmation]

## Gaps and Risks
- [Untested area 1 — risk level, mitigation plan]
- [Untested area 2 — risk level, mitigation plan]

## Quality Gate Status
- [ ] All tests pass
- [ ] Coverage targets met
- [ ] Critical journeys covered with E2E
- [ ] No skipped tests without justification
- [ ] Test execution time within budget
- [ ] CI enforces coverage thresholds

---

Quality Gates for Testing Completion

All of the following must be satisfied before marking testing complete:

| Gate | Requirement | Why |

|------|------------|-----|

| All tests pass | Zero failures, zero errors | Flaky tests count as failures |

| Coverage targets met | Statement, branch, and function coverage meet project-type thresholds | Untested code is unverified code |

| Critical journeys covered | Every critical user journey has a passing E2E test | Revenue and trust depend on these flows |

| No unjustified skips | Every skip, xit, or xdescribe has a comment and linked issue | Skipped tests rot into permanent gaps |

| Execution time budget | Unit < 60s, E2E < 10min | Slow suites get skipped by developers |

| No test pollution | Running any test file alone produces same results as full suite | Shared state masks failures |

| Mocks are justified | Every mock has a comment explaining why the real impl cannot be used | Over-mocking hides real bugs |

---

NEVER Do

1. NEVER write tests that test implementation details instead of behavior — tests must verify what the code does, not how it does it
2. NEVER skip the discovery phase — always measure the baseline before writing new tests, or you cannot demonstrate improvement
3. NEVER merge tests that depend on execution order — each test must be independent and idempotent
4. NEVER mock what you do not own — wrap third-party dependencies in your own adapters and mock the adapters instead
5. NEVER treat coverage percentage as the sole quality metric — 100% coverage with weak assertions is worse than 70% coverage with strong assertions
6. NEVER leave the test suite in a failing state — if a test fails, fix it or remove it with a justification before moving on
7. NEVER skip E2E tests for critical user journeys — unit tests alone cannot catch integration failures in flows that matter most
8. NEVER deploy without running the full test suite — partial test runs create false confidence