PlaybookPrompts

Write unit tests from a function signature and spec

Coding & Development testingunit-teststdd

Writing tests after the fact is tedious and often incomplete. This prompt generates a structured test suite from a function signature and its intended behavior, covering happy paths, edge cases, and known failure modes.

Prompt
You are a test engineer writing a thorough unit test suite. I will give you a function signature and a description of its intended behavior.

Language and test framework: {{LANGUAGE_AND_FRAMEWORK}} (e.g. Python + pytest, TypeScript + Jest)

Function signature:
```
{{FUNCTION_SIGNATURE}}
```

Behavior description:
{{BEHAVIOR_DESCRIPTION}}

Any known edge cases or constraints:
{{KNOWN_EDGE_CASES}}

Follow these steps:

1. List the categories of test cases you plan to cover before writing any code: happy paths, boundary conditions, invalid inputs, and any state-dependent scenarios.
2. Write one test per behavior, not one test per function. Name each test so it reads as a sentence describing what it verifies (e.g. `test_returns_empty_list_when_input_is_none`).
3. For each test, include a one-line comment stating the specific condition being tested.
4. If the function has side effects (writes to DB, calls external API), write tests using mocks or stubs and show the mock setup explicitly.
5. After the tests, list any behaviors that you could not test without more information and explain what is missing.

Do not test implementation details — only observable behavior. Do not use `assert True` or trivially passing assertions.
Variables to fill in
  • {{LANGUAGE_AND_FRAMEWORK}}
  • {{FUNCTION_SIGNATURE}}
  • {{BEHAVIOR_DESCRIPTION}}
  • {{KNOWN_EDGE_CASES}}

How to use this prompt

  1. Copy the prompt above (Copy button on the top-right).
  2. Replace each {{VAR}} with your own value. Variables: {{LANGUAGE_AND_FRAMEWORK}}{{FUNCTION_SIGNATURE}}{{BEHAVIOR_DESCRIPTION}}{{KNOWN_EDGE_CASES}}.
  3. Paste it into one of the recommended tools below.
  4. Iterate: tighten constraints in the prompt if the output is generic.

Why this prompt is structured this way

The prompt is split into explicit steps because LLMs do better when the path is named, not implied. Each variable forces specificity at the input layer — vague inputs get vague outputs.

Heads up: some of the links on this page are affiliate links — meaning we may earn a commission if you sign up after clicking, at no extra cost to you. We only recommend tools we'd put on our own stack. You can see our full affiliate disclosure here.

Pair this prompt with a tool

The PlaybookPrompts weekly

One short email per week. The five sharpest prompts we found, one tool worth your attention, one anti-pattern to avoid. Unsubscribe in one click.

Newsletter signup is not configured. Set PUBLIC_NEWSLETTER_USERNAME in the build env.