Writing tests for a function

Generate a test suite that covers edge cases you'd likely forget, not just the happy path.

Copying runs entirely in your browser - nothing here is ever sent anywhere.

Fill in the variables

Write tests for the following {{language}} function using {{test_framework}}.

Cover, in this order:
1. The happy path - typical, expected input.
2. Boundary values - empty input, zero, negative numbers, the smallest and
   largest values the function is likely to see.
3. Invalid input - wrong types, null/undefined/None, malformed data - and
   what the function should do with them (raise, return a default, etc).
4. Any concurrency or ordering assumption the function makes, if relevant.

For each test, name it after the behavior it verifies (not "test1",
"test2"), and add a one-line comment above any non-obvious edge case
explaining why it's being tested.

If the function's behavior is ambiguous for some input (e.g. it's unclear
what should happen on empty input), don't guess silently - write the test
for what you infer, but flag the assumption in a comment.

Function:
{{code}}

When to use

Right after writing a new function, before you’ve had time to convince yourself it already works. Also useful on legacy code with no tests at all, where the goal is a baseline safety net before refactoring.

Why it works

Most people’s own test-writing defaults to the happy path because that’s the case they were thinking about while writing the function. Explicitly ordering boundary and invalid-input cases forces coverage of the cases that actually cause production bugs. Naming tests after behavior (not sequence numbers) makes a failing test log readable months later.

Variations

Add “Also write one test that would have caught this specific bug: {{bug description}}” when writing a regression test for something that already broke.
For a function with external dependencies (a database call, an API), ask for the tests with those dependencies mocked, and specify your mocking library.
Ask for property-based tests instead of example-based ones if the language/ecosystem supports it (e.g. Hypothesis for Python, fast-check for TypeScript) and the function’s contract is simple enough to state as a property.