Test Case Generator Prompt

Asked to “write some tests,” a model tends to cover the happy path and stop there — exactly the scenarios you’d have thought of yourself. The value of AI-generated test cases is systematic coverage of what human recall tends to skip under time pressure: negative cases, boundary values, and edge cases. That only shows up if you explicitly ask for those categories rather than leaving test type unstated.

This template requests specific test categories, structures output as clear preconditions, steps, and expected results rather than bare titles, and asks the model to flag anything that depends on business logic it can’t infer from the source material.

The core template

Act as a senior QA engineer generating test cases for this feature.

Language/testing framework: [e.g., Python + pytest, JavaScript + Jest, or "no code -- structured test case descriptions only"]

Feature to test: [paste the code, or describe the feature/user story with its acceptance criteria]

Test types to generate: [happy path | negative cases | edge cases | boundary values | security scenarios -- select which apply, or say "all"]

Format: [Given-When-Then | numbered steps with expected results | your team's existing test case template]

For each test case, provide a clear title, preconditions, steps, and the expected result. Flag any case that depends on business logic or domain knowledge not evident from the source material, rather than guessing at the correct expected behavior.

Why each slot matters

• Test types to generate. The single highest-leverage slot — without it, coverage defaults to happy-path scenarios, which is exactly what human testers already tend to write from memory. Naming negative, edge, and boundary categories explicitly is what makes AI generation add coverage you didn’t already have.
• Feature to test, with real acceptance criteria. Test cases generated from a vague feature description drift toward generic scenarios that could apply to almost any feature. Pasting the actual code or a real user story with acceptance criteria anchors the cases to what this specific feature actually needs to do.
• Format. Given-When-Then structures each case around a precondition, a trigger, and a verifiable outcome — integrates directly with BDD frameworks if that’s your workflow. Numbered steps work better for manual QA processes. Either way, naming the format up front avoids cases coming back as a loose paragraph.
• Structured output (preconditions, steps, expected result), not just titles. A list of test case titles without steps or expected results isn’t actually usable — it’s a to-do list, not a test suite. Requiring the full structure is what makes the output something you can act on directly.
• The “flag rather than guess” instruction. Test cases for business logic the model can’t verify from the source material need a human to confirm the expected behavior — a confidently wrong expected result is worse than an honest gap, since a wrong test case can pass while the actual behavior is broken.

Three filled-in examples

Example 1 — API endpoint, Given-When-Then format

Example 2 — User story, no code yet

Example 3 — Security-focused test generation

Common mistakes this template helps avoid

• Asking for “tests” without specifying test types. This is the single most common reason AI-generated test suites skew toward happy-path coverage — exactly the scenarios that needed the least AI assistance to think of.
• Accepting bare test titles as finished output. A title without preconditions, steps, and an expected result isn’t an executable or reviewable test case — it’s a placeholder.
• Skipping human review before adding cases to the suite. Generated cases should go through the same review any test would, particularly for anything flagged as dependent on business logic the model couldn’t verify.
• Generating tests from a vague feature description instead of real acceptance criteria. Vague input produces generic cases that could apply to almost any similar feature — specific acceptance criteria produce specific, useful tests.

Frequently asked questions

How much of the generated output should I expect to use as-is?

Most of it, if the input was specific — teams commonly report the large majority of generated cases are usable with minimal edits when working from clear acceptance criteria or well-structured code. The remainder typically needs adjustment where business logic wasn’t fully evident from the source material, which is exactly what the “flag rather than guess” instruction is meant to surface.

Should I select all test types every time?

For a new feature with no existing coverage, yes — a full baseline across all categories is usually the right starting point. For an established feature getting incremental changes, scoping to just the categories relevant to the change (as in the security-focused example above) produces more targeted, faster-to-review output.

Does this replace exploratory testing?

No — AI-generated cases are systematic coverage of scenarios that can be inferred from requirements or code, not a substitute for a human tester actually exploring the application and noticing something that wasn’t specified anywhere. The two complement each other; neither fully replaces the other.

Can I use this for API testing specifically?

Yes — the template works well for API endpoints specifically, and boundary and security test types tend to be particularly valuable there (invalid payloads, authentication failures, rate limit behavior, unexpected content types).

How is this different from the code review and debugging prompt templates?

Different purpose entirely. The code review template evaluates existing code, and the debugging template diagnoses broken code. This one generates new test coverage for code or features that may not have any tests yet, which calls for a completely different structure focused on scenario coverage rather than evaluation or diagnosis.

Next steps

Once test cases are generated and reviewed, consider running the Code Refactoring Prompt Template against any code that lacked test coverage before this pass — refactoring against a fresh test suite is meaningfully safer than refactoring without one. For more ready-to-use templates, browse the Prompt library.