Engineering

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.

Open in Test Case Prompt Generator

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.

How to use this resource

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

FAQ

How does this prompt decide which dependencies to mock versus leave real?

The TEST STRATEGY draws the line at the unit boundary: every external dependency (it names database, network, clock, filesystem) is mocked or stubbed, while nothing internal to the unit is. Generate the contract with the Test Case Prompt Generator and run it in ChatGPT, Claude, or Gemini; the model applies that rule, but you confirm the mock boundary matches your actual code before trusting the tests in CI.

Why does the prompt tell the model to skip getters, mappers, and pass-throughs?

Because the strategy tests business logic and decisions, not plumbing. Getters, mappers, and pass-throughs earn a test only when they carry a rule, so the model spends coverage on branches that make decisions instead of padding the file with trivial assertions. The generated prompt encodes that priority; the assistant you run it in still decides case by case, so review which methods it chose to skip.

Which failure scenarios does this contract force tests for that hand-written suites usually miss?

The FAILURE SCENARIOS block names four that each get at least one test: a mocked dependency throwing, invalid arguments at every public entry point, boundary returns from dependencies (empty result, null, maximum size), and state-dependent behavior called in the wrong state. The prompt makes the model attempt all four; you still run the resulting tests to confirm each path actually triggers as asserted.

Where do I look when the generated tests can't cover a behavior?

Read the ASSUMPTIONS and GAPS headings the OUTPUT FORMAT requires after the test file. ASSUMPTIONS list guesses the model made about unspecified behavior; GAPS list behaviors it could not test with the information given. Treat GAPS as a to-do list: feed the missing context back into the prompt and regenerate, rather than shipping those untested paths unexamined.

Customize This Resource

Opens this setup in Test Case Prompt Generator. Generate to get the full test contract — then adjust the strategy, framework, coverage, and depth.

Open in Test Case Prompt Generator

Prompt Template

Copy it as-is, or use Open in Test Case Prompt Generator to load it pre-filled and customize it with your own context.

TESTING OBJECTIVE
Unit test the customer service's business logic with its dependencies mocked.
Strategy: unit tests — isolate the unit, mock its dependencies, test the business logic.
Generate tests only — do not modify the implementation.

CODE CONTEXT
[Paste the code under test here]

TEST STRATEGY
- Test one unit in isolation: every external dependency (database, network, clock, filesystem) is mocked or stubbed.
- Test business logic and decisions, not plumbing — getters, mappers, and pass-throughs earn tests only when they carry rules.
- One behavior per test; the test name states behavior, condition, and expected result.
- Tests must be fast and deterministic — no real I/O, no real time, no ordering dependence.

COVERAGE AREAS
Happy Path:
- The primary success path with realistic, typical inputs
- The most common variations users actually exercise
- Expected outputs asserted precisely — values and shape, not just "no exception"
Error Handling:
- Every declared error path actually triggers in a test
- Errors carry the right type, message, and code
- Failures leave state clean — no partial writes survive
- Errors propagate or are swallowed exactly as specified
Validation:
- Required fields missing — one at a time, each with its own test
- Invalid formats: emails, dates, IDs, and the patterns the code claims to enforce
- Invalid state transitions rejected with the specified behavior
- Business rule violations tested at their exact boundaries

FAILURE SCENARIOS
Each of these gets at least one test:
- A mocked dependency throws — the unit handles or propagates as specified
- Invalid arguments at every public entry point
- Boundary returns from dependencies (empty result, null, maximum size)
- State-dependent behavior called in the wrong state

TEST DATA GUIDANCE
- Use realistic, production-shaped data — names, amounts, and dates that could exist.
- Build complex objects with builders or factories, not hand-assembled literals repeated per test.
- Name boundary data for its intent (maxLengthName, expiredToken), not its value.
- Never share mutable fixtures between tests.

FRAMEWORK GUIDANCE
Framework: Generic.
- Use the project's existing test framework and follow its established conventions.

OUTPUT FORMAT
- Return one complete, runnable test file.
- Group tests by coverage area, with a comment header per group.
- Each test: arrange-act-assert structure, one behavior per test.
- Cover every selected coverage area systematically — each coverage item above gets at least one test.
- Parametrize repetitive cases instead of copy-pasting tests.
- Name tests so a failure message alone identifies the broken behavior.

ASSUMPTIONS
- After the tests, list every assumption you made about unspecified behavior under an ASSUMPTIONS heading.
- Where the code's intent is ambiguous, test the most likely intent and flag the ambiguity.
- List GAPS: behaviors you could not test with the information given.

NON-GOALS
- Do not rewrite or "improve" the implementation code — test it as it is.
- Do not refactor the architecture to make it more testable; flag testability problems instead.
- Do not invent requirements — test only specified or clearly implied behavior.
- Do not weaken assertions to make tests pass.

More resources from Test Case Prompt Generator

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

Resource

Agent Safety & Refusal Evaluation Prompt

Test the two failure directions — does the agent refuse what it must, and does it stay helpful on the benign requests it shouldn't over-refuse?

AI Agents

Resource

Agent Test Scenario Prompt

Build the test set an agent has to pass — scenarios across the happy path, edges, and adversarial inputs, each paired with the expected behavior to grade against.

AI Agents

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Test Case Prompt Generator

Build test generation prompts — unit, integration, or E2E — with framework modes and edge-case coverage rules.

Coding Workflows

Projects that use this resource

Project

Build a SaaS MVP with AI

The full path from idea to a shipped SaaS MVP — define and scope the requirements, design the architecture, API, and data model, then build it reviewed, tested, secured, cost-controlled, and deployed.

11 stages Product Build

Project

Build an API Backend with AI

The full path to a backend you can put clients on — define the requirements, design the architecture, API contract, data model, and access control, then build it reviewed, tested, secured, and shipped.

9 stages Software Development

Project

Modernize a Legacy Codebase with AI

The full path to taming an inherited codebase — understand it, document its architecture, pin its behavior with tests, then refactor, modernize, review, speed up, and ship it without breaking what works.

8 stages Software Development

Project

Build a Marketplace with AI

The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.

10 stages Software Development

Project

Build an E-commerce Store with AI

The full path to a store you own end to end — model the catalog and orders, design the storefront and checkout, add customer accounts and payments, then secure it, test it, and ship.

10 stages Commerce

Workflows that use this resource

Workflow

AI Test Generation Workflow

Build a test suite that fails for real reasons, not green decoration — coverage across unit, integration, and edge cases, then a review for the gaps.

5 steps 30–60 minutes

Tip: Save time by exploring related resources and tools that integrate with this resource.