Prompt template
A unit test prompt that tests behavior, not implementation trivia.
This template gives a coding agent the contract, dependencies, edge cases, and project conventions required to write focused tests. It discourages over-mocking, weak assertions, and tests that simply repeat the implementation.
Reviewed September 22, 2026 · Templates and examples use fictitious data.
When to use this unit test prompt
Use it after the behavior of a function, service, hook, or component is understood well enough to state as a contract. It works for adding coverage to existing code, protecting a bug fix, or specifying a small new behavior before implementation.
Do not ask for “all possible tests.” Identify the risks that matter: incorrect boundary handling, wrong errors, duplicate side effects, authorization mistakes, time-dependent behavior, or nondeterministic dependencies.
Reusable template
Unit test generation prompt
# Unit tests for {{subject}}
## Context
- Project: {{project}}
- Language, framework, and test runner: {{language_framework}}
- Observable behavior contract: {{behavior_contract}}
- External dependencies and boundaries: {{dependencies}}
- Known edge cases: {{edge_cases}}
- Existing test conventions: {{test_style}}
<instructions>
Inspect the implementation and nearby tests before writing new tests. Test observable behavior rather than private implementation details. Cover a realistic happy path, contract failures, boundary values, and the supplied edge cases.
Mock only real boundaries such as network, storage, time, randomness, or external services. Do not weaken assertions, duplicate implementation logic inside tests, or change production behavior merely to make a test pass. Label assumptions when the contract is incomplete.
</instructions>
<output_format>
1. Behavior and risk coverage matrix
2. Assumptions or missing contract details
3. Complete test code following the project's conventions
4. Commands to run the focused tests
5. Remaining gaps that require integration or end-to-end coverage
</output_format>What the agent needs before writing tests
{{subject}}
The function, class, service, hook, or component under test.
{{behavior_contract}}
Inputs, outputs, errors, state changes, and side effects visible to a caller.
{{dependencies}}
Real boundaries such as storage, network, time, randomness, queues, or external services.
{{test_style}}
Nearby examples, naming conventions, fixtures, factories, and the preferred mocking approach.
Filled example: idempotent order creation
Subject: createOrder(command) in a TypeScript service using Vitest.
Contract: A new idempotency key creates one order; a repeated key returns the existing order; invalid totals fail before persistence.
Dependencies: Order repository and payment client. The repository is the transaction boundary.
Edge cases: Concurrent calls with the same key, payment timeout, zero total, and repository conflict.
Style: Use existing builders, explicit assertions, and fake timers only for timeout behavior.
A useful answer should distinguish what can be proven with isolated unit tests from the concurrency case that may require a real transactional integration test.
Reject tests that only look convincing
- Assertions describe caller-visible behavior and meaningful outputs.
- Failure paths verify both the error and forbidden side effects.
- Mocks represent real boundaries instead of every collaborator.
- Test data includes realistic and boundary values.
- Remaining integration and end-to-end gaps are stated explicitly.
Unit tests are one layer
A passing unit suite does not prove database constraints, browser behavior, network contracts, or deployment configuration. Ask for the smallest higher-level test when the risk crosses a real boundary, and never let generated tests weaken an established production contract.