The prompt
Score 10 of 10, Excellent
Use it when You have a single function and want focused tests that cover the normal cases, the edges and the errors, in your project's test framework.
- {{function_code}}
- {{language}}
- {{test_framework}}
- {{intended_behavior}}
- {{example_test}}
Full prompt and why it works
Prompt
<function_code> {{function_code}} </function_code> <context> Language: {{language}} Test framework: {{test_framework}} What the function is supposed to do: {{intended_behavior}} An existing test from the project to copy for style: {{example_test}} </context> <constraints> - Test behavior through the function's inputs and outputs, not its internals. - One behavior per test, with a name that says what it checks, for example returns_zero_for_empty_cart. - Cover, in this order: normal inputs; boundary values (empty, zero, one, the maximum, negative numbers where relevant); invalid input and the errors it should raise; then any branch not reached yet. - Replace network calls, files, clocks and random values with fakes or fixed values. Do not add libraries beyond {{test_framework}} and what the example test already uses. - Where the code and the intended behavior disagree, do not write the test to match the code. Write it for the intended behavior, mark it as expected to fail, and explain why in a comment. </constraints> <format> 1. The test file in one code block, ready to save, with imports. 2. A table with the columns Test name, Input, Expected result, Why it matters. 3. Possible bugs: any input where the code seems not to match the intended behavior, one sentence each. </format> <task> Write between 6 and 15 unit tests for the function above, so that a later change that breaks its behavior fails at least one test. Make sure each test would fail if the behavior it checks were broken. If the intended behavior is unclear for some input, such as whether an empty string is allowed, do not guess: list it as a question after the table instead of writing a test for it. </task>
Variables
- {{function_code}}
- The function, plus any small helpers or types it uses.
- {{language}}
- The language and version, for example TypeScript or Python 3.12.
- {{test_framework}}
- For example Jest, Vitest, pytest, JUnit 5 or Go's testing package.
- {{intended_behavior}}
- What the function should do, including the rules for bad input. The tests check this, so be precise.
- {{example_test}}
- One existing test from your project, so the new tests match its style. Write "none" if there is none.
Why it works
- Who it's for. The tests exist to catch a later change that breaks behavior, which is why each one checks a single behavior and must fail if that behavior breaks.
- What to avoid. Where code and intended behavior disagree, the test follows the intended behavior and is marked as expected to fail, so a bug is never locked in as correct.
- Layout. Code first, then context, rules and format in XML-style tags, with the task last: the order Google recommends for Gemini.