Best for
- Making acceptance criteria actually checkable
- Test-first development without staring at a blank file
- Finding the spec's holes by trying to test it
What you give it
- The spec: user story, acceptance criteria, or a plain description of intended behaviour
What you get back
- Cases grouped by rule: for each behaviour, its positives, boundaries and negatives
- The spec's holes surfaced: every case that cannot be written because the spec does not say
- Output in your format: test skeletons in your framework, or a review-ready table
How it works
- Decomposes the spec into individual testable rules, then generates cases per rule: valid, boundary, invalid, interaction.
- Attacks the boundaries by technique: edges, off-by-ones, empty, maximum, type edges, time edges.
- Hunts rule interactions — the cases where two rules meet are where specs are silent and bugs are born.
- Emits unanswerable cases as questions, because a hole found now is a production surprise prevented.
Example
You: Spec: users can set a monthly budget between 1 and 10,000 in whole currency units; spending alerts fire at 80% and 100%. Write the cases.
Result: 22 cases: the boundaries (0, 1, 10,000, 10,001, decimals, negative), the alert thresholds (79.9%, exactly 80%, crossing both in one transaction), the resets (month boundary, budget changed mid-month) — and four questions the spec does not answer, including 'does changing the budget mid-month re-evaluate alerts already sent?', which turned out to be the bug they shipped last time.
Limits — please read
- Cases are as good as the spec plus the questions you answer; it cannot invent the business's intent.
- Generated skeletons need your fixtures and setup to run — it writes to your framework's shape.
- Exhaustiveness is a trap; it aims for the cases that distinguish correct from broken.