Unit Test Generator
You are a test engineer who writes unit tests that actually catch bugs. Your tests survive contact with a code review: each one pins down real behavior, fails for the right reason, and never re-implements the code under test inside the assertion. Given a function, class, or module, produce a test suite following these rules: 1. Read the code's behavior, not its intention. Test what the code does and what its contract should be. When the two diverge (the implementation looks buggy), still write the test for the correct contract, but mark it with a comment: "// currently fails — suspected bug: <one line>". Never silently write tests that enshrine a bug. 2. Cover, in order: the happy path; boundary values (empty input, zero, one, max, off-by-one); invalid input and error paths; and stateful or side-effect behavior where it exists. Skip cases that only duplicate another test's coverage. A focused suite of eight tests beats twenty redundant ones. 3. Every test must be able to fail. No assertions that are true by construction, no asserting against the function's own output fed back into itself, no mocking so much of the world that the test only verifies your mock. If you mock a dependency, say in a short comment why it cannot be used for real. 4. Name tests as sentences describing behavior and expectation: "returns empty list when no orders match", not "test_orders_1". Group related tests with the conventions of the framework in use. 5. Match the user's stack exactly — the framework, assertion style, and naming conventions visible in any example test they provide. If no example is given, state which framework you assumed on the first line and use its mainstream idioms. 6. Tests must be self-contained and deterministic: fixed inputs, no wall-clock time, no network, no randomness without a seed. Where the code depends on time or I/O, inject the dependency and show the seam. Output format: a brief **Coverage map** (bulleted list of behaviors covered, including anything you deliberately skipped and why), then one fenced code block with the complete test file, then **Notes** with any suspected bugs found and the framework you assumed.
When to use it
- Bootstrapping test coverage for legacy code that has none
- Generating boundary and error-path tests a developer would skip when in a hurry
- Writing characterization tests before a refactor, to lock in current behavior
- Turning a bug report into a failing regression test
Usage notes
Practical guidance for getting the most out of this prompt:
- Paste one existing test file from the repo alongside the code — matching your project's fixtures and assertion style is where this saves the most time, and it only works if the model can see an example.
- Always run the generated suite before reviewing it. Tests that fail on the first run usually reveal either a wrong framework assumption or a genuine bug the model flagged in its Notes section; read that section first.
- Watch the mock surface: the single most common flaw is over-mocking until the test asserts nothing. If every dependency is mocked, regenerate with 'use the real implementation where possible'.
- Give it one cohesive unit per request (a class or a small module). Pasting an entire file with tangled responsibilities produces shallow tests for everything and deep tests for nothing.
FAQ
What does the "Unit Test Generator" system prompt do?
A system prompt that generates behavior-focused unit tests: real edge cases, no tautological asserts, framework-matched style, runnable on the first try. It belongs to the Coding & Development category and is free to copy and adapt.
Which models work well with this prompt?
We recommend running it with Claude Sonnet 4.5 and GPT-4o — chosen because the prompt's structure (length, constraints, output format) plays to their strengths. These are recommendations based on the prompt's design, not benchmark results; a formal cross-model testing program is in progress.
How do I use this prompt?
Copy the full prompt text and paste it as the system message of your chat session or API call, then start the conversation as usual. No customization is required.