Test case generator from a spec

Read a feature spec and produce test cases (happy path, edge cases, failure modes).

The prompt

Copy this verbatim. Replace the {{ … }} placeholders with your values.

<instructions>
Read the feature spec in <spec>. Produce a test plan inside <result> tags as JSON.

For each test case:
{
  "id": "TC-001",
  "category": "happy_path | edge_case | failure | security | performance",
  "preconditions": ["string"],
  "steps": ["string"],
  "expected": "string",
  "rationale": "string — why this case matters"
}

Coverage rules:
- At least 2 happy_path cases.
- At least 4 edge_cases (boundary, empty, max-size, concurrency, unicode).
- At least 2 failure cases (invalid input, downstream error).
- 1 security case if user input is involved.
- 1 performance case if SLA/throughput is mentioned.
- IDs zero-padded sequentially: TC-001, TC-002, ...
</instructions>

<spec>{{ feature_spec }}</spec>

Return inside <result> tags.

Sample input

Spec: a new POST /api/comments endpoint that creates a comment on a post. Auth required. Comment max 500 chars. Returns 201 with comment ID.

Expected output

<result>
[
  {"id": "TC-001", "category": "happy_path",
   "preconditions": ["valid auth token", "existing post_id"],
   "steps": ["POST /api/comments with {post_id, body: 'hi'}"],
   "expected": "201 with comment id in response",
   "rationale": "minimal create-flow validation"},
  // 9 more cases covering 500-char boundary, empty body, missing auth,
  // non-existent post_id, XSS payload, unicode emoji, etc.
]
</result>

Notes & tuning tips

• Coverage rules with numeric floors force the model to think about each category, not just the happy path.
• Pair with a static linter on the spec — if the spec is vague, the test plan inherits that vagueness.
• Generated tests are a starting point. Always have a human review for missed risks.

What this example uses

Tags: <instructions> <format>

Patterns: structured output

More like this