testing-strategy

Maps business logic into layered test scenarios across unit, integration, contract, and e2e levels.

Updated Apr 26, 2026
One-click install
npx skills add https://github.com/Jin9/skillify-foundation --skill testing-strategy-jin9
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing-strategy
Source: https://github.com/Jin9/skillify-foundation/tree/main/treasury/testing-strategy
Command: npx skills add https://github.com/Jin9/skillify-foundation --skill testing-strategy-jin9

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often chase coverage percentages while their tests assert nothing meaningful, leaving business logic paths untested and boundary drift discovered only in production. This Skill turns a requirement's business rules into a concrete, layered test strategy so coverage guarantees behavior rather than a number. ## Core Features & Use Cases - Layered Test-Level Plan: Decides what to test at unit, integration, contract, e2e, and regression levels, with an owner assigned to each. - Business-Logic-to-Scenario Mapping: Converts every business rule into happy-path, failure-path, and boundary scenarios, plus edge-case parameters like null, max, duplicate, and overflow. - Contract-Test Boundaries: Identifies consumer-driven contract points (e.g., Pact for service/REST boundaries, tool-schema governance for agent boundaries) between unit and e2e levels. - Use Case: Given a wallet top-up feature, the Skill produces a strategy covering ledger math unit tests, a consumer-driven Pact contract for the provider callback, one e2e happy-path journey, and edge cases like duplicate callbacks and zero amounts. ## Quick Start Ask the agent to turn this feature's business logic into a layered test strategy with scenario mapping and contract-test boundaries.

Frequently Asked Questions about testing-strategy

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

FAQPage Schema
How do I decide which test levels my feature needs?▼

Map each business rule to the cheapest level that guarantees it: unit tests for isolated domain logic, integration tests for handler and infra wiring, contract tests for service boundaries, and e2e only for critical user journeys. Assign an owner to each level.

How to turn business logic into test scenarios?▼

For every business rule, write a happy-path, failure-path, and boundary scenario, then enumerate edge-case parameters such as null, max, duplicate, and overflow values. Target 100% coverage of business logic, not of lines of code.

What is a contract test and when should I use one?▼

A contract test sits between unit and e2e levels and verifies that a consumer and provider agree on an interface without running both sides. Use consumer-driven contracts like Pact for service or REST boundaries, and tool-schema governance for agent tool boundaries.

Why does 100% code coverage still leave bugs?▼

High coverage with weak assertions means tests execute lines without verifying behavior. Treat the coverage number as a smoke alarm and require tests that assert outcomes, such as balance and ledger state, rather than just a 200 OK response.

When should I not use this test strategy skill?▼

Do not use it to localize a specific failing test or bug, which belongs to a debugging workflow, or for security test cases, which belong to a security review skill. It designs the strategy, not the diagnosis.