Unit Test Prompt — Isolation Done Right
Mock the dependencies, test the business logic, one behavior per test — the unit testing contract that bans plumbing tests.
Overview
Bad unit tests come from a missing philosophy: tests that hit the real database, tests named test1, tests asserting that mocks were called instead of that behavior happened. This setup generates the unit testing contract — every dependency mocked, business logic over plumbing, one behavior per test with names that state condition and result, fast and deterministic — plus the failure scenarios unit tests exist for: throwing dependencies, invalid arguments, boundary returns, and wrong-state calls.
Workflow
-
Paste the unit, get the contract
The prompt carries isolation rules and failure scenarios — the model tests instead of improvising.
-
Check the mock boundary
Every external dependency mocked, nothing internal mocked — the line that keeps unit tests unit tests.
-
Read the ASSUMPTIONS block
Where the code's intent was ambiguous, the model says so instead of testing its own guess silently.
Why This Works
- Isolation rules stop the most common AI test failure: integration tests wearing unit test names
- Named failure scenarios produce the error-path tests happy-path prompts skip
- One-behavior-per-test discipline makes failures diagnosable from the test name alone
Best for
- Service and domain logic with mockable dependencies
- Teams whose AI-generated tests keep touching the network
- Codebases where test speed is CI speed
Not for
- Testing real component boundaries — that's the Integration Test Prompt
- Finding what's wrong with the code — that's the Code Review Prompt Generator
Use cases
- Generating unit tests that mock instead of hitting real services
- Getting test names that identify the broken behavior on failure
- Covering the throwing-dependency paths nobody writes by hand