Prompt
You are an experienced test engineer. Write unit tests for the function I paste, following my project's test style.

Language and test framework: {{framework}}
The function under test:
{{code}}
The intended behavior, in my own words (the spec): {{spec}}

Produce:
1. A short list of behaviors and edge cases worth testing, derived from the intended behavior — not only from what the code currently does. Include boundary values, empty and null inputs, error paths, and any invariant I described.
2. The test code, one clearly named test per behavior, following {{framework}} conventions.
3. A note of any behavior you could not test because the spec is ambiguous or a dependency needs mocking.

Rules:
- Where the code's actual behavior contradicts the intended behavior I described, write a FAILING test that asserts the intended behavior and flag it — do not adjust the test to match a possible bug.
- Use only the framework, assertions, and mocking tools standard to {{framework}}; do not import packages or helpers you are not certain exist.
- Do not assert on private internals or exact log strings that would make the tests brittle.

Fill in your details and the prompt updates live — then copy.

What you get back (excerpt)

Behaviors to test: normal discount applied; discount capped so price is never negative; negative price rejected; null customer handled; zero-quantity order. # pytest def test_applies_percentage_discount(): assert final_price(100, 0.2) == 80 def test_rejects_negative_price(): with pytest.raises(ValueError): final_price(-1, 0.2) Note: your spec says price should never go below zero, but the code returns a negative value for discounts over 100%. I wrote test_price_never_negative as a FAILING test asserting the intended behavior. Could not test currency rounding — the spec did not define it.

The full workflow

  1. Write down the intended behavior yourself first — the spec, not just what the code does
  2. Generate the tests, then read each one and confirm it asserts what you actually want
  3. Run the suite; investigate any failure as a possible real bug, not a test to silence
  4. Add the cases the model missed and delete the brittle or redundant ones

Watch out for

Tests generated from the code alone pass by construction and prove nothing — they lock in current behavior, bugs included. Supply the intended behavior separately and check that any failing test points to a real defect.

Verify that any library or test helper the model imports actually exists. Studies found roughly one in five AI-suggested packages are hallucinated, and attackers register those names as malware (a supply-chain trick called slopsquatting) — never add AI-suggested dependencies unchecked.

Keep proprietary code and real customer data out of consumer AI tools — use dummy fixtures, or an enterprise tier with training turned off.

Where this comes from

Every use case on this site is grounded in real reports from working software developers — not invented by us.

More AI use cases for software developers

← All 6 use cases: How Software Developers Use AI