Test generation prompt builder
Good tests are tedious to write and easy to skimp on, which is exactly why LLMs help — if you ask correctly. A loose “write some tests” yields a couple of happy-path cases. The test generation prompt builder assembles a prompt that names your language and framework, your coverage goals, and the rules for real assertions, so the model returns a suite that exercises edge cases, boundaries, and failure modes too.
How it works
You pick a language and a matching test framework, paste a function signature, docstring, or full implementation, and check the coverage categories you want — happy path, edge cases, boundary values, failure modes, and idempotency or side effects. The tool composes a prompt that requires idiomatic framework structure, behavior-describing test names, a specific assertion in every test, and explicit flags for any behavior the spec leaves ambiguous. It runs locally with no API key. You paste the prompt into your LLM and review the suite it produces.
What each coverage category contributes
Happy path tests confirm that the function does what it is supposed to do in the ideal case. These are necessary but not sufficient — a function that passes its happy-path tests can still fail on empty input, at boundaries, or in error conditions.
Edge cases probe the boundary between valid and invalid inputs. For a string function, edge cases include empty string, strings with only whitespace, strings containing Unicode or emoji, and very long strings. For a numeric function, they include zero, negative values, and very large numbers. These are the inputs most likely to reveal off-by-one errors and unhandled conditions.
Boundary values target the exact boundaries defined by the spec — the maximum allowed value, the minimum, and the values immediately above and below those thresholds. If a function accepts ages between 18 and 65, the boundary tests check exactly 18, exactly 65, 17, and 66.
Failure modes test what happens when the function receives invalid input or encounters an error condition. Does it throw the right exception? Return the correct error code? Not silently swallow the problem? These tests are frequently skipped and consistently the location of production bugs.
Idempotency and side effects tests check that calling the function multiple times produces the same result, and that it does or does not mutate state as specified. These are particularly important for database operations, file writes, and anything with external effects.
Providing a clear spec to the model
The most important input is the docstring or specification. The model derives the expected return values from it — if the spec says the function returns the square root of the input for positive numbers and raises ValueError for negative numbers, the model can write concrete assertions like assert sqrt(9) == 3.0 and with pytest.raises(ValueError). Without a precise spec, the model defaults to plausible assertions that may not match the actual intended behavior.
If you paste only the implementation, the model will observe what the code does and test that — which is useful for preventing regression but can miss the gap between what the code does and what it should do.
Tips and notes
- Lead with a clear spec. The model derives expected values from your docstring — a precise spec yields correct assertions.
- Always run the output. Generated tests are a draft; run them and fix any that encode a wrong assumption rather than trusting them blind.
- Add failure modes deliberately. Untested error paths are where bugs hide; keep that box checked for anything user-facing.
- Pair with debugging. When a test surfaces a real bug, feed it into the debugging prompt builder to get a targeted fix.