test-strategy

Designs testing strategies with coverage targets, shift-left practices, and release test plans.

1|Updated Mar 18, 2026
One-click install
npx skills add https://github.com/MARUCIE/openclaw-foundry --skill test-strategy-marucie
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-strategy
Source: https://github.com/MARUCIE/openclaw-foundry/tree/main/web/public/packs/spellbook-test-engineer/skills/test-strategy
Command: npx skills add https://github.com/MARUCIE/openclaw-foundry --skill test-strategy-marucie

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams struggle to decide how many unit, integration, and E2E tests to write, what coverage targets to enforce, and how to plan QA for releases. This Skill provides a structured testing strategy framework covering model selection, coverage enforcement, shift-left practices, and non-functional testing. ## Core Features & Use Cases - Testing Model Selection: Compares the Pyramid, Trophy, and Honeycomb models with a decision table matching models to architectures like monoliths, frontends, and microservices. - Coverage Target Setting: Defines realistic line and branch coverage targets per codebase type with CI enforcement examples for pytest, Jest, and Go. - Shift-Left & Non-Functional Testing: Covers pre-commit hooks, Pact contract tests, property-based testing, k6 load tests, and Playwright accessibility checks. - Use Case: Before a major release, use the included test plan template to document scope, environments, entry/exit criteria, and risk areas so QA sign-off is explicit. ## Quick Start Ask the AI to design a testing strategy for a new microservices project including coverage targets and a release test plan.

Frequently Asked Questions about test-strategy

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

FAQPage Schema
How do I choose between the test pyramid, trophy, and honeycomb models?▼

Choose the pyramid for monoliths with complex business logic, the trophy for frontend-heavy apps where integration tests reflect user behavior, and the honeycomb for microservices where service integration tests matter more than isolated units.

What code coverage target should I set for my project?▼

Set 80% or higher for new projects, raise legacy coverage by 5% per sprint using a ratchet, and require 95% plus branch coverage for critical paths like payments and auth. Exclude generated code and migrations from measurement.

How do I enforce coverage thresholds in CI with pytest or Jest?▼

In pytest, add --cov-fail-under=80 and --cov-branch flags in pyproject.toml. In Jest, set coverageThreshold globals for lines and branches in package.json so CI fails when coverage drops below the floor.

When should I use contract testing with Pact?▼

Use Pact whenever services communicate over APIs, since a broken contract between services causes production outages. Consumer-driven contract tests catch mismatched request and response shapes in CI before deployment.

Why is high line coverage not enough for test quality?▼

High line coverage can coexist with zero behavior coverage when tests assert on implementation details or use trivial mocks. Track branch coverage and mutation scores to verify tests actually catch logic errors.

What are the limitations of E2E tests for edge cases?▼

E2E tests are slow and fragile, so they should cover only critical user journeys. Edge cases and error paths belong in unit or integration tests where they run faster and fail with clearer signals.