What this prompt does
This prompt makes the AI a senior test engineer that turns a plain-English behaviour spec into real, runnable tests rather than a description of what to test. You give it your [framework], your [conventions], and the [spec] itself. It produces six things: happy-path tests asserting the core behaviour, edge cases for boundaries and empty inputs and the spec's special rules, error and auth paths using the exact status codes or exceptions named in the spec, tests written against observable behaviour rather than private internals, reuse of your existing fixtures and naming, and clear test names that read as sentences.
The structure works because it forces coverage of the cases people skip in a hurry: the error and auth paths, and the boundary conditions stated in the spec rather than only the obvious happy path. [framework] decides the test syntax and assertion style so the file drops straight into your suite without translation. [conventions] is what keeps the output consistent with your project, reusing existing factories and fixtures and the Arrange-Act-Assert shape instead of a foreign structure the team has to relearn. The insistence on testing observable behaviour, not internals, is deliberate so the tests survive refactors instead of breaking on every change and teaching the team to ignore red.
When to use it
- You have a behaviour spec and want tests written before the code.
- You want the error and auth cases you would otherwise skip in a hurry.
- You need tests that match your project's existing conventions and fixtures.
- You want tests pinned to behaviour so they survive refactors.
- You are locking down an API's contract before changing its implementation.
- You want test names that read as sentences describing expected behaviour.
Example output
You get a complete test file in your framework: happy-path tests asserting the core behaviour, edge-case tests for boundaries and empty inputs and the spec's special rules, and error and auth tests using the exact status codes or exceptions from the spec, all written against observable behaviour and reusing your fixtures and naming with test names that read as sentences. Below it is a one-line note on any spec ambiguity the model assumed away, so you can confirm or correct its interpretation before relying on the suite.
Pro tips
- Write
[spec]with concrete rules and exact status codes; vague specs yield vague tests. - Set
[framework]exactly so the assertions and runner syntax match your suite. - Describe
[conventions]in detail (fixtures, AAA, naming) so tests stay consistent. - Read the ambiguity note; it tells you where the model guessed, so you can correct it.
- Keep tests on observable behaviour; internal-pinned tests break on every refactor.
- Name the exact exceptions or codes in the spec so error-path tests assert the right thing.
