design-testing-strategy

Designs test strategies using deterministic decision gates, ISTQB techniques, and a structured YAML schema.

1.5k|154|Updated Nov 13, 2025
One-click install
npx skills add https://github.com/NeoLabHQ/context-engineering-kit --skill design-testing-strategy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-testing-strategy
Source: https://github.com/NeoLabHQ/context-engineering-kit/tree/main/plugins/tdd/skills/design-testing-strategy
Command: npx skills add https://github.com/NeoLabHQ/context-engineering-kit --skill design-testing-strategy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Deciding which test types (unit, integration, e2e, contract, property-based) a piece of code actually needs is often ad-hoc and inconsistent. This Skill replaces guesswork with deterministic decision gates, explicit skip heuristics, and an enforced output schema so every test strategy is justified and reproducible.

Core Features & Use Cases

  • Deterministic Decision Gates: Seven ordered gates (Skip All, Unit, Integration, Component/E2E, Contract, Smoke, Property-Based) with explicit ON/OFF conditions grounded in 14 industry sources including the Test Pyramid, Testing Trophy, and Google Test Sizes.
  • Case Design Techniques: Applies ISTQB black-box methods (Equivalence Partitioning, Boundary Value Analysis, Decision Tables, State Transition) plus table-driven test patterns to derive concrete test cases.
  • Enforced Output Schema: Produces a test_strategy YAML block with load-bearing field ordering and a Test Cases to Cover markdown list linked to acceptance criteria.
  • Use Case: Before writing tests for a new POST /users endpoint, run the gates to decide that unit, integration (Testcontainers Postgres), and contract (Pact) tests apply, while e2e and smoke are explicitly rejected with documented reasons.

Quick Start

Ask the agent to design a testing strategy for a specific function, endpoint, or UI component before writing any tests for it.

Frequently Asked Questions about design-testing-strategy

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

FAQPage Schema
How do I decide which test types to write for my code?

Apply the seven decision gates in order: each gate turns a test type ON or OFF based on concrete conditions like boundary crossing, UI surface, and criticality level. Then apply strategic skip heuristics to remove low-ROI selections and document rejected types with reasons.

What is the difference between unit, integration, and e2e tests?

Unit tests cover pure logic in a single function with no I/O, integration tests cross boundaries like databases or HTTP using real infrastructure such as Testcontainers, and e2e tests drive a full user path through a running app with a real browser and backend.

Playwright vs Cypress for end-to-end testing?

Playwright supports Chromium, Firefox, and WebKit with built-in parallelism and robust network interception, making it the default for new projects. Cypress fits teams with existing investment, though it has limited multi-tab support and paid parallelization.

When should I use property-based testing?

Use property-based testing when the input domain is large or unbounded, stable invariants exist such as round-trip or idempotency, and criticality is MEDIUM-HIGH or higher. Skip it for small finite domains where equivalence partitioning and boundary value analysis already suffice.

When is it acceptable to skip writing tests?

Skip tests when criticality is NONE: docs-only changes, formatting, generated code, configs without logic, or throwaway prototypes. Also skip e2e for internal helpers, contract tests for single-consumer APIs deployed together, and integration tests for pure functions.