test-strategy

Designs a testing pyramid strategy with coverage targets, tooling selection, and CI quality gates.

1|Updated Mar 21, 2026
One-click install
npx skills add https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts --skill test-strategy-kalilurrahman
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-strategy
Source: https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts/tree/main/07-testing-quality/test-strategy
Command: npx skills add https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts --skill test-strategy-kalilurrahman

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams without a deliberate test strategy either test too little and ship production bugs, or over-invest in slow, brittle E2E suites. This Skill produces a structured testing strategy that defines what to test, at which layer, with which tools, and what must pass before code ships. ## Core Features & Use Cases - Testing Pyramid Design: Defines proportions for unit, integration, contract, E2E, and performance tests with per-layer coverage targets. - Tooling Selection: Produces a concrete tooling stack (pytest, Playwright, Pact, k6, testcontainers) with rationale per layer. - CI Quality Gates: Generates GitHub Actions workflows with coverage thresholds, flakiness SLAs, and quarantine policies. - Use Case: A team building a Python FastAPI service with PostgreSQL uses this Skill to get a complete test directory structure, pytest fixtures with testcontainers, factory_boy test data, and a CI pipeline that enforces 80% unit coverage before merge. ## Quick Start Ask the assistant to design a test strategy for your application by specifying your tech stack, team size, and deployment frequency.

Frequently Asked Questions about test-strategy

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

FAQPage Schema
How do I design a testing pyramid for my application?

Allocate roughly 60-70% unit tests, 20-30% integration tests, 5% contract tests, and 5-10% E2E tests. Unit tests cover pure logic with no I/O, integration tests use real databases via testcontainers, and E2E tests cover only the top critical user journeys.

What test coverage target should I set for each layer?

Set 80% line coverage for unit tests measured per file in CI, cover critical endpoint and database paths for integration, 100% of consumed APIs for contract tests, and only the top 5 user journeys for E2E. Coverage is a proxy, not a goal; strong assertions matter more than the number.

Should I use pytest or unittest for Python testing?

Standardize on one framework per layer; pytest is recommended for its fixtures, parametrization, and plugin ecosystem like pytest-xdist for parallel runs and pytest-cov for coverage. Mixing pytest and unittest in the same suite adds maintenance overhead.

How do I handle flaky tests in CI?

Flag any test that fails and passes on re-run without code changes, then apply SLAs: fix CI-blocking flakes within 24 hours or quarantine them with a reruns marker and a linked issue. Never delete a failing test without understanding the root cause or fix timing issues with sleep calls.

When should E2E tests run in the CI pipeline?

Run fast tests first: unit tests on every push, integration tests on pull requests, and E2E tests against staging rather than on every PR. E2E tests are slow and brittle, so restrict them to critical user journeys and schedule performance tests nightly.