Awesome Claude Prompts Unofficial

Write unit tests

Get unit tests for a function or module in your framework, covering normal cases, edge cases and errors, with each test explained.

Task: Write unit tests · Other tasks

Fill in the details

Include the code you want covered and any small helpers it calls. Remove secrets first.

Optional. List rules the code must follow, especially ones that are not obvious from reading it.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

2 required fields are empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

  • You have a function or small module without tests and want a solid first set to review and adapt.
  • You are adding a feature and want tests that state the expected behavior before you change the code.
  • You want a list of edge cases you might have missed, written as runnable tests in your framework.

When not to use it

  • The code needs a running database, browser or network service to do anything meaningful. That calls for integration tests and a setup you will need to describe in detail.
  • You need tests for a large codebase at once. Work one module at a time so you can review each set properly.
  • You cannot run the tests yourself. Generated tests are a draft until you have run them and checked that they fail for the right reasons.

Why this structure

  • The code sits first inside <code> tags, and the framework and rules follow it, so the material comes before the instructions as Anthropic's long-context guidance suggests.
  • The framework is a required field because test syntax, fixtures and assertions differ a lot between frameworks; naming it avoids tests you have to translate.
  • The optional list of required behaviors captures rules that cannot be read from the code, which is where the most useful tests come from.
  • Asking for the list of cases before the code lets you spot missing or unnecessary cases quickly, before reading every test.
  • The last paragraph tells Claude to test intended behavior and to flag suspicious code rather than freeze a possible bug into a passing test.

Example input (fictional)

Code to cover
def apply_discount(price, percent):
    if percent < 0 or percent > 100:
        raise ValueError("percent must be 0-100")
    return round(price * (1 - percent / 100), 2)
Test framework
pytest
Behaviors that must be covered
Rejects percentages outside 0 to 100. Rounds to 2 decimal places.
Test style
Thorough: also edge and error cases

Follow-ups to send Claude

  • Run through each test and tell me which ones would still pass if the rounding line were removed.
  • Add a parametrized test that covers the boundary values in one place.
  • Two tests failed with the output below. Is the test wrong or the code?

Common mistakes

  • Not saying which framework and version you use. You may get tests in the wrong syntax or with fixtures your setup does not support.
  • Accepting tests that only repeat the implementation. A useful test checks an outcome from the outside, not the same arithmetic written twice.
  • Skipping the run. A test that has never failed has not shown that it can catch anything; break the code on purpose once to see it fail.
  • Code review prompt: Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.
  • Debug an error: Turn an error message and the code around it into a ranked list of likely causes, a check for each, and a fix you can try.

See all templates

Sources