What this prompt does
This prompt turns a block of existing source code into a full unit test suite. You paste your code into [code], and the AI generates tests in [language] using [test_framework], producing at least [min_cases] cases for every public method. Each method gets happy-path, edge-case, error/exception, and boundary-value coverage, so the result is a real safety net rather than a few token assertions.
The structure works because it forces breadth before depth. By requiring [mock_library] for external dependencies, the [naming_convention] naming style, logical grouping, and a [coverage_target]% coverage floor, the prompt stops the model from writing only the obvious tests. Setup/teardown and parameterized data providers are requested explicitly, so methods with many input shapes get table-driven tests instead of copy-pasted near-duplicates. The variables let one template fit PHPUnit, Jest, pytest, or whatever suite the project already runs.
When to use it
- You inherited a service with thin or zero coverage and need a baseline before refactoring.
- You want exception and boundary tests written quickly, not just happy paths.
- You are standardising test naming and structure across a team.
- You need parameterized tests for a method that takes many input combinations.
- You want to raise coverage toward a specific
[coverage_target]figure. - You are reviewing whether a class is even testable as written.
Example output
You get a single test file (or class) in [language] with grouped test methods named in your [naming_convention] style. Each public method has multiple cases, mocks are wired through [mock_library], setup/teardown blocks initialise shared fixtures, and methods with varied inputs use data providers. Comments usually flag which branch each test exercises.
Pro tips
- Paste real, compilable code into
[code]— the more complete the class, the fewer hallucinated method signatures you get. - Match
[test_framework]and[mock_library]to what the project actually uses, or you will get tests that do not run. - Keep
[min_cases]modest (2–3) for wide classes; high values balloon output and dilute quality. - A
[coverage_target]of 90+ is aspirational on legacy code; treat generated tests as a draft and verify they actually assert behaviour, not just call methods. - Set
[naming_convention]to your existing pattern so the new tests read like the rest of the suite. - Run the generated suite immediately; fix any tests that pass trivially or assert nothing meaningful.
