test-strategy

Designs test pyramids, coverage targets, and tooling choices across unit, integration, and E2E layers.

Updated Sep 10, 2026
One-click install
npx skills add https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula --skill test-strategy-serpro-workshop-fortaleza
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-strategy
Source: https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula/tree/main/.github/skills/test-strategy
Command: npx skills add https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula --skill test-strategy-serpro-workshop-fortaleza

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often lack a coherent testing strategy, ending up with inverted test pyramids, arbitrary coverage numbers, and flaky E2E suites that erode confidence instead of building it. ## Core Features & Use Cases - Risk-Based Test Distribution: Classifies modules by risk (P0/P1/P2) and allocates the test pyramid (70% unit, 20% integration, 10% E2E) with justified deviations. - Coverage Targets and Flake Budgets: Sets baseline coverage goals (80% lines, 90% for P0 modules) and a maximum 1% flaky-test rate with quarantine rules. - Tool Selection per Layer: Recommends tools such as Vitest/JUnit/pytest for unit tests, Testcontainers for integration, and Playwright for E2E. - Use Case: When modernizing a legacy system, use this Skill to audit the existing test suite, classify module risk, and produce a one-page strategy document with targets, tools, and quarantine rules. ## Quick Start Ask the assistant to create a test strategy for your system, including the test pyramid distribution, coverage targets, and tooling per layer.

Frequently Asked Questions about test-strategy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a test strategy for a software project?

Inventory the tested code, classify modules by risk (P0/P1/P2), then distribute tests across the pyramid: 70% unit, 20% integration, 10% E2E. Set coverage targets per risk level and document tools, thresholds, and quarantine rules in a one-page strategy.

What is the ideal ratio of unit, integration, and E2E tests?

A common starting point is 70% unit tests, 20% integration tests, and 10% E2E tests. Deviations are acceptable when justified by system characteristics, but an inverted pyramid with mostly slow E2E tests is an antipattern.

What test coverage percentage should I target?

A baseline of 80% line coverage is reasonable, with a higher bar of 90% for P0 (highest-risk) modules. Track branch coverage separately and treat coverage as a confidence indicator, not a goal in itself.

Which tools should I use for unit, integration, and E2E testing?

Use Vitest, JUnit, or pytest for unit tests, Testcontainers for integration tests against real dependencies, and Playwright for end-to-end tests. Prefer contract tests over mocks for anything crossing service boundaries.

How do I handle flaky tests in my test suite?

Set a flaky-test budget of at most 1% of the suite. When the rate exceeds that threshold, move the offending tests into quarantine so they stop blocking pipelines while they are investigated and fixed.

When should I avoid writing E2E tests?

Avoid E2E tests when the same behavior can be verified with integration and contract tests, which are cheaper and more stable. Reserve E2E tests for the main user journeys only, since they are slow and prone to flakiness.