Test Suite Generator from Source Code

The Prompt

You are a senior {{language}} test engineer. Generate a practical, high-signal test suite for the code below and adapt the output for a {{workflow_surface}} workflow.

Test framework:
{{test_framework}}

Code under test:
{{code_under_test}}

Critical behavior that must not break:
{{critical_paths}}

Validation commands:
{{validation_commands}}

Return output in this exact structure:
1) Risk-based test plan (what matters most and why)
2) Prioritized test cases table (P0/P1/P2 with short rationale)
3) Edge cases and failure-mode tests
4) Table-driven or parameterized test matrix where applicable
5) Runnable starter test file in {{test_framework}}
6) Workflow-surface notes
   - what a CLI or IDE agent can implement safely right away
   - what still needs human clarification
7) Verification loop (exact commands to run, expected pass signals, what to inspect if failures appear)
8) Gaps and assumptions (what cannot be tested from current context)

Constraints:
- Focus first on behavior correctness, then edge cases, then implementation details.
- Avoid brittle tests coupled to private internals.
- Prefer deterministic tests; mock external systems explicitly.
- Include at least one negative test per critical path.
- Flag missing fixtures, helpers, or repo conventions that block a clean test draft.

When to Use

Use this when you have working code but weak test coverage, or when you want a fast first draft of meaningful tests that fits how modern coding tools are actually used. It works well for functions, modules, service handlers, and data transforms whether implementation happens in a CLI agent, an IDE agent, or after planning in a separate app.

Best use cases:

• New feature shipped without enough tests
• Legacy code where test debt has accumulated
• Refactors where you need confidence before changes
• Bugs that should be locked down with regression tests

This prompt is designed for practical output, not academic completeness. You get a prioritized list and runnable starter tests you can paste directly into your codebase and iterate.

Variables

Variable	Description	Good input examples
language	Programming language of the code	TypeScript, Python, Java
test_framework	Framework and style requirements	Vitest, Jest, Pytest, JUnit 5
code_under_test	Actual source code or key excerpt	Class, function, endpoint handler
critical_paths	Business-critical behaviors to protect	”payment success path”, “retry backoff logic”
workflow_surface	Where the follow-up implementation happens	"CLI agent", "IDE agent", "planning app before coding"
validation_commands	The checks that prove the generated tests fit the repo	bun run build, bun test, pytest -q, pnpm vitest run

Tips & Variations

• Ask for “minimum high-value suite under 30 minutes” when you need speed.
• Add “include fixture factory helpers” for repeated test setup.
• Add CI constraints like “tests must run under 2 minutes.”
• For API code, request explicit status code and error body assertions.
• CLI agents are strong for broader backfills; IDE agents are better for tight assertion edits after you inspect the file locally.
• If you plan in ChatGPT or Claude first, ask for the test matrix and failure modes before asking a coding agent to write the file.
• After generating tests, run a second prompt: “Suggest missing cases based on a mutation-testing mindset.”
• If the code under test is large, narrow scope to one module and one critical path first. A smaller but real suite beats a giant speculative draft.

If output is too broad, narrow scope to one module and one critical path per run. Iterative prompts usually produce better tests than one giant request.

Example Output

P0: Returns 401 when auth token is missing.

P1: Retries network timeout exactly 3 times with exponential backoff.

Verification loop: Run bun test auth-handler and confirm the new negative tests pass before asking the agent for wider cleanup.

Starter test snippet (Vitest):

it("returns 401 when token is missing", async () => {
  const res = await handler(mockReqWithoutToken);
  expect(res.status).toBe(401);
});