test-matrix

Builds a test matrix with assertion strategy, lane, and spec level per case.

10|7|Updated Feb 23, 2026
One-click install
npx skills add https://github.com/xiaolai/tdd-guardian-for-claude --skill test-matrix-xiaolai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-matrix
Source: https://github.com/xiaolai/tdd-guardian-for-claude/tree/main/skills/tdd-guardian/test-matrix
Command: npx skills add https://github.com/xiaolai/tdd-guardian-for-claude --skill test-matrix-xiaolai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests without a plan leads to shallow coverage: missing boundary cases, mock-only assertions that verify wiring instead of behavior, and no property tests for units that have real invariants. This Skill forces an explicit test matrix before any test code is written. ## Core Features & Use Cases - Seven coverage categories: success paths, boundary values, guard clauses, failure paths, state transitions, determinism, and properties/invariants. - The law question: each unit must declare its invariant (round-trip, idempotency, conservation) or explicitly state why none exists, with property-based cases required when a law exists. - Three independent axes per case: lane (unit/integration/e2e/contract), assertion level (behavior over wiring), and specification level S1-S6. - Mock pairing rule: every mocked boundary must name a paired integration test covering the real path. - Use Case: Before implementing a payment retry function, produce a matrix covering success, timeout retries, idempotency on duplicate calls, and a property test asserting the retry count never exceeds the configured maximum. ## Quick Start Ask the AI to build a test matrix for the function or module you are about to implement, covering all categories with lane and assertion strategy per case.

Frequently Asked Questions about test-matrix

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

FAQPage Schema
How do I plan test cases before writing code?

Build a test matrix listing each case with its category, input, expected output, observable side effect, and assertion strategy. Cover seven categories: success, boundary, guard clauses, failure paths, state transitions, determinism, and properties.

What is a property-based test and when do I need one?

A property-based test verifies an invariant over generated inputs rather than listed examples. You need one whenever a unit has a law such as a round-trip, idempotency, conservation, or ordering; example-only tests under-specify such units.

When should I mock a dependency in unit tests?

Mock only true system boundaries like Docker daemons, networks, or child processes, and non-deterministic calls like Date.now. Never mock your own modules; use real implementations, in-memory databases, or temporary directories instead.

Why do mock-only tests give false confidence?

Mock-only tests assert wiring, such as call arguments, rather than observable behavior, so they pass even when the real collaborator is broken. Every mocked boundary must be paired with an integration test exercising the real path.

How do I choose between unit, integration, and e2e test lanes?

Assign each case to the cheapest lane where a failure would be real. Ask whether the test would still pass if the real collaborator were broken; if yes, the case belongs one lane higher.