codingtesting

Unit Test Suite Generator

Generates comprehensive unit tests covering happy paths, edge cases, error handling, and boundary conditions.

Prompt

You are a QA engineer writing unit tests. Generate a comprehensive test suite for the following [language] function/class using [testing framework, e.g. Jest, pytest, JUnit]. For each test, provide: a descriptive test name following the pattern 'should [expected behaviour] when [condition]', the test code with arrange-act-assert structure, and a comment explaining what's being tested. Cover these categories: (1) Happy path: 3-4 tests for normal expected inputs, (2) Edge cases: empty inputs, single elements, maximum values, boundary conditions, (3) Error handling: invalid inputs, null/undefined, wrong types, (4) Integration points: mock external dependencies (show mock setup). Additional requirements: use beforeEach/setUp for shared test fixtures, group related tests in describe/context blocks, include at least one parameterised test if the framework supports it, and add a test for any race condition or async behaviour if applicable. Here is the code to test:

```[language]
[PASTE CODE HERE]
```

Why this prompt works

The category breakdown (happy path, edge cases, error handling, integration points) is the key move. Most prompts that just say 'write tests for this code' produce four happy-path tests and call it done. Naming the four categories forces the model to reason about each one separately, and the edge-cases bullet is specific enough (empty inputs, single elements, boundary conditions) that it catches the cases people actually forget. The arrange-act-assert structure plus the 'should X when Y' naming pattern enforces a test style that reads like documentation rather than noise. The score is 87 rather than 100 because the prompt is light on context about why each test category matters; for most use cases that's fine.

When to reach for it

You've just finished writing a function and want a test scaffold before you've thought too hard about what could go wrong.
You're inheriting code with no tests and need a baseline coverage layer before refactoring it.
You want a second pair of eyes on edge cases for code that handles user input or data from external services.
You're writing tests in a language you're less fluent in (e.g. a Go developer writing pytest) and want idiomatic structure for that ecosystem.

How to customise it

Replace the language and framework brackets first. The framework matters more than the language. Jest and Vitest get nearly identical output, but JUnit produces something noticeably more verbose because of the framework's conventions. If the function under test has external dependencies, name them explicitly when you paste the code (for example, 'this uses the stripe-node SDK'); the prompt's mock setup hint is generic, and pointing at specific libraries gets you mocks that compile. For property-based testing, replace 'parameterised test if the framework supports it' with the name of your tool: fast-check for JS, hypothesis for Python, and so on.

What good output looks like

For a 30-line JavaScript function you'll typically get 8 to 12 tests grouped into describe blocks for happy path, edge cases, errors, and integration. Each test has the arrange-act-assert structure laid out as separate lines, with a one-line comment above explaining what's being verified. Mocks are set up in beforeEach. The naming is consistently 'should X when Y'. What you won't get for free is realistic test data: the model uses placeholders like 'validInput' and 'mockUser' that you'll usually want to replace with values resembling your actual production payloads.

Watch out for

The prompt covers the test categories explicitly but doesn't tell the model how strict to be about coverage. If the function has internal branching (multiple if/else paths), the generated tests often only hit the obvious branches. Add 'aim for 100% branch coverage and explain any branches you skip' to push the model harder. Also, the 'parameterised test if the framework supports it' line is permissive enough that the model often skips it. If you want one, ask for it directly.

unit testingtest suiteJestpytestTDDtestingChatGPT / Claude