test-strategy

Designs test strategies by matching test distribution models to system architectures.

1|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/TheViziusGroup/vibe-engineering-skills --skill test-strategy-theviziusgroup
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-strategy
Source: https://github.com/TheViziusGroup/vibe-engineering-skills/tree/main/plugins/quality-engineering/skills/test-strategy
Command: npx skills add https://github.com/TheViziusGroup/vibe-engineering-skills --skill test-strategy-theviziusgroup

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often accumulate slow, flaky, or misallocated test suites that consume CI time without providing deployment confidence. This Skill provides a framework for choosing the right test distribution, evaluating suite health, and closing risk gaps across testing layers. ## Core Features & Use Cases - Architecture-Matched Test Shapes: Select between the Test Pyramid (monoliths), Testing Trophy (API/frontend apps), and Honeycomb model (microservices), with the Swiss Cheese model for communicating layered risk to stakeholders. - Suite Health Diagnostics: Apply Google's SMURF framework (Speed, Maintainability, Utilization, Reliability, Fidelity) plus mutation testing with mutmut or cosmic-ray to validate that tests actually detect bugs. - Methodology and Tooling Guidance: Covers TDD vs BDD vs ATDD selection, consumer-driven contract testing with Pact and can-i-deploy gates, property-based testing with Hypothesis, test doubles taxonomy, and performance/security testing integration. - Use Case: A team migrating to microservices asks how to restructure their tests. The Skill recommends the Honeycomb model, prescribes Pact contract tests for service boundaries, and produces a one-page test strategy document with quality gates. ## Quick Start Ask the assistant to design a test strategy for your microservices architecture, including the recommended test distribution and contract testing approach.

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 and testing trophy?

Choose the test pyramid for monolithic applications where unit-level isolation is cheap and informative. Choose the testing trophy for API-centric or frontend-heavy applications, where integration tests through the HTTP layer with a real database provide more confidence than isolated unit tests.

When should I use contract testing with Pact?

Use contract testing when microservices deploy independently. If services always deploy together, contract tests are unnecessary. Pact verifies consumer-provider compatibility, and the can-i-deploy command gates production deployments on verified contracts.

What is the difference between TDD, BDD, and ATDD?

TDD is a design practice using red-green-refactor cycles for new code. BDD is a format using Gherkin syntax so stakeholders can read test specifications. ATDD is a collaboration process where business, development, and testing roles agree on behavior before development begins.

Should I use a mock, stub, or fake in my tests?

Use stubs or fakes for I/O boundaries like network and disk. Use mocks only when you must verify an interaction occurred. Use fakes such as in-memory repositories for unit tests and real databases via testcontainers for integration tests, and never mock your ORM directly.

Why is high code coverage not enough for test quality?

Coverage measures execution, not verification. A suite can hit 90% coverage while failing SMURF dimensions like reliability and fidelity. Mutation testing with tools like mutmut reveals whether tests actually detect bugs; scores below 60% indicate significant gaps.

When is property-based testing with Hypothesis not appropriate?

Property-based testing fits pure functions, parsers, serializers, and round-trip properties. It is a poor fit for UI flows, performance testing, scenarios with complex setup and teardown, and anything requiring real external services.