Testing
Generate Meaningful Unit Tests for Existing Code
Produce tests that cover real behaviour and edge cases instead of trivially asserting implementation details.
The Prompt
generate-unit-tests-for-existing-code.md
You are a test engineer. Write tests that would catch real regressions. Test framework: {{framework}} Code under test: ``` {{code}} ``` Known important behaviours: {{behaviours}} Deliver: 1. A short list of behaviours worth testing, ordered by risk 2. The test file, using {{framework}} conventions, with clear test names describing behaviour 3. Coverage of: happy path, boundary values, invalid input, error paths, async/timing issues if relevant 4. Minimal mocking, with a note on why each mock exists 5. Cases you deliberately did NOT test and why 6. Any refactor that would make this code substantially easier to test Do not assert on private internals. Tests must fail for the right reasons.
Negative prompt
Included when you copy the prompt
Do not assert on private internals, mock call order trivia, or implementation details that can change without breaking behaviour. Do not write tests that only prove the mock was called. Do not skip unhappy paths and boundaries listed as important. Do not over-mock until the unit under test does nothing real. Do not invent a different test framework than {{framework}}. Do not claim 100% coverage as the goal when risk-based coverage is enough.
Fill in your details below - this prompt updates as you type, then copy it.
Fill in your details
0 of 3 filled. Preview updates as you type - then copy the finished prompt (negative prompt included when present).
generate-unit-tests-for-existing-code.md
Prompt preview
You are a test engineer. Write tests that would catch real regressions. Test framework: {{framework}} Code under test: ``` {{code}} ``` Known important behaviours: {{behaviours}} Deliver: 1. A short list of behaviours worth testing, ordered by risk 2. The test file, using {{framework}} conventions, with clear test names describing behaviour 3. Coverage of: happy path, boundary values, invalid input, error paths, async/timing issues if relevant 4. Minimal mocking, with a note on why each mock exists 5. Cases you deliberately did NOT test and why 6. Any refactor that would make this code substantially easier to test Do not assert on private internals. Tests must fail for the right reasons.
Examples
Example input
Framework: Vitest Code: export function calcShipping(cents: number, country: string): number { if (cents < 0) throw new Error("invalid"); if (country === "US") return cents >= 5000 ? 0 : 599; if (country === "CA") return 999; return 1499; } Behaviours: Free US shipping at $50+; reject negative totals; default international rate.
What you should get
1. Behaviours by risk: negative input throws; US free threshold; US below threshold; CA rate; other countries default. 2. Tests (excerpt): ```ts describe("calcShipping", () => { it("throws on negative subtotal", () => { expect(() => calcShipping(-1, "US")).toThrow("invalid"); }); it("gives free US shipping at 5000 cents", () => { expect(calcShipping(5000, "US")).toBe(0); }); it("charges 599 US below threshold", () => { expect(calcShipping(4999, "US")).toBe(599); }); it("charges 999 for CA", () => { expect(calcShipping(100, "CA")).toBe(999); }); it("charges 1499 for other countries", () => { expect(calcShipping(100, "GB")).toBe(1499); }); }); ``` 3. Covered: happy, boundary (4999/5000), invalid, no async needed. 4. Mocks: none - pure function. 5. Not tested: currency conversion (not in code); tax. 6. Refactor: Named constants for thresholds/rates would make intent clearer; not required for testability.
How to get a good result
Done when
1. Behaviours by risk: negative input throws; US free threshold; US below threshold; CA rate; other countries default. 2. Tests (excerpt): ```ts describe("calcShipping", () => { it("throws on negative subtotal", () => { expect(() => calcShipping(-1, "US")).toThrow("invalid"); }); it("gives free US shipping at 5000 cents", () => { expect(calcShipping(5000, "US")).toBe(0); }); it("charges 599 US below threshold", () => { expect(calcShipping(4999, "US")).toBe(599); }); it("charges 999 for CA", () => { expect(calcShipping(100, "CA")).toBe(999); }); it("charges 1499 for other countries", () => { expect(calcShipping(100, "GB")).toBe(1499); }); }); ``` 3. Covered: happy, boundary (4999/5000), invalid, no async needed. 4. Mocks: none - pure function. 5. Not tested: currency conversion (not in code); tax. 6. Refactor: Named constants for thresholds/rates would make intent clearer; not required for testability.
FAQ
- What do I fill in before I copy this prompt?
- Replace these placeholders with your details: framework, code, behaviours. Required fields are marked on the page. The prompt text updates as you type.
- Which AI tools is this prompt written for?
- It works best with ChatGPT, Claude, Cursor. Copy the filled prompt and paste it into the tool you already use.
- What should a good result look like?
- 1. Behaviours by risk: negative input throws; US free threshold; US below threshold; CA rate; other countries default. 2. Tests (excerpt): ```ts describe("calcShipping", () => { it("throws on negative subtotal", () => { expect(() => calcShipping(-1, "US")).toThrow("invalid"); }); it("gives free US shipping at 5000 cents", () => { expect(calcShipping(5000, "US")).toBe(0); }); it("charges 599 US below threshold", () => { expect(calcShipping(4999, "US")).toBe(599); }); …
Best for
- Developers
- QA engineers
- Tech leads
Related Prompts
More prompts like this — same topic and style.
