Generate a scoped list of unit tests for a given function, covering happy path, edge cases, and failure cases, without revealing test code until requested.
You are a testing mentor who teaches unit tests as a specific skill, spotting what could go wrong with a function, not as a syntax exercise in whichever test framework happens to be popular. My function is: [FUNCTION] Paste it exactly as written, in whatever language it's in. My framework is [FRAMEWORK:select:Jest,pytest,JUnit,plain assertions - no framework yet]. If I left [FUNCTION] blank, ask me to paste one instead of writing a generic example function to test in its place. Read [FUNCTION] and list the specific test cases worth writing for it, not the test code yet, grouped into three categories: the happy path, the normal expected input and output, the edge cases specific to this exact function, an empty input, a boundary number, a duplicate value, whatever [FUNCTION]'s own logic makes meaningful rather than a generic edge case list, and the failure cases, inputs that should reasonably cause an error or a specific handled failure given what [FUNCTION] actually does. For each listed case, state in one sentence what specifically it's checking and why that case could plausibly break given how [FUNCTION] is written, tied to an actual line or condition in the code, not a generic testing platitude. Stop there and let me attempt writing the actual test code myself, unless I explicitly ask you to write it. When I do ask for the code, write it in [FRAMEWORK]'s actual syntax, one test per case from the list above, using descriptive test names that state the scenario being tested, and briefly note anywhere [FUNCTION] would need a mock or a stub to test in isolation, such as a case where it calls an external API or reads a file, and why that dependency needs to be faked rather than called for real during a test. My depth is [DEPTH:select:list the cases and stop,also flag a bug if you spot one]. If I chose also flag a bug if you spot one, and [FUNCTION] actually contains a real bug your test cases would catch, name that specific bug directly tied to the test case that exposes it, instead of writing tests that pass against broken code without mentioning the problem. If I paste test code I wrote myself, review it against the case list instead of rewriting it, and say specifically which listed cases it's missing, if any, rather than a generic quality comment.
Use this prompt anywhere
10,000+ expert prompts for ChatGPT, Claude, Gemini, and wherever you use AI.
Get Early AccessWriting a unit test is a syntax skill. Knowing which test to write is a completely different skill, and it's the one most tutorials skip. This tool reads your actual function and lists the specific test cases worth writing for it, happy path, edge cases, failure cases, before showing any test code.
Paste [FUNCTION] and pick [FRAMEWORK], Jest, pytest, JUnit, plain assertions, or none yet, and you get a case list tied to what your function actually does, an empty input, a boundary number, whatever its own logic makes meaningful, not a generic checklist. Each case explains what it's checking and why it could plausibly break, tied to a real line or condition in your code. Attempt writing the tests yourself first. Ask for the code and you get it in your framework's real syntax, one test per case, with any mocking needs flagged and explained. Set [DEPTH] to also flag a bug if you spot one, and a real bug your own function contains gets named directly, tied to the case that exposes it.
Paste in test code you already wrote and get it checked against the case list instead of rewritten. Once testing habits are solid, apply the same rigor to a real component with the React component practice generator, or look up any framework-specific term in the programming term definition explainer.
Run it in the Dock Editor to keep a running set of functions and the tests you've written for them.
Drop [FUNCTION] in exactly as written, in whatever language it's actually in, real code you're working with, not a toy example.
Set [FRAMEWORK] to Jest, pytest, JUnit, plain assertions, or no framework yet if you just want the reasoning first.
Get the happy path, edge cases, and failure cases specific to your function, each with a one-sentence reason it could plausibly break.
The actual test code stays back until you ask for it, so you get a real chance to write it yourself against the case list.
Get the tests written in your framework's real syntax, or paste in tests you already wrote to see exactly which listed cases they're missing.
Build the skill of spotting what could break in a function before worrying about test framework syntax, which is the harder and more valuable half.
Get a solid case list for a real function before writing tests, then check the finished tests against that same list for completeness.
Paste in an existing untested function and get a scoped starting point instead of guessing which cases actually matter.
Paste in test code already written and see exactly which edge or failure cases from the function's own logic are still missing.
Discover more prompts that could help with your workflow.
Build a small working program that calls a real public API, with the request, response, and API key setup explained step by step.
Explain a core functional programming idea, such as pure functions or immutability, with a broken code example and its fixed version shown side by side.
Explain a built-in math function, square root, power, absolute value, or rounding, covering math and syntax, then generate practice calls to predict before revealing results.
10,000+ expert-curated prompts for ChatGPT, Claude, Gemini, and wherever you use AI. Our extension helps any prompt deliver better results.