Engineering

Integration Test Prompt — the Boundary Is the Subject

Real database, real services, real transactions — integration tests that verify round-trips and rollback, not mocked theater.

Open in Test Case Prompt Generator

Overview

Integration tests fail their purpose when they mock the very boundary they exist to test. This setup generates the integration contract for a CRUD service against its real database layer: data round-trips verified end to end, transaction behavior tested explicitly (commits commit, rollbacks leave no debris), each test owning its setup and teardown — with failure scenarios that only exist at boundaries: constraint violations surfacing as the right errors, downstream timeouts mid-operation, partial failure leaving clean state, concurrent access to the same data.

How to use this resource

Point it at the boundary

The service plus its real database — the contract treats the seam as the subject, not an inconvenience.
Trust the transaction scenarios

Half-failed operations and rollback verification are the tests that pay for themselves in one incident.
Keep tests self-owning

Each test sets up and tears down its own data — the rule that keeps integration suites parallel-safe.

Why This Works

Boundary-as-subject framing stops the mock-everything reflex
Transaction scenarios test the failure modes mocked tests structurally cannot see
Setup/teardown ownership keeps the suite honest as it grows

Best for

Data-access layers whose unit tests mock away the truth
Services where transaction boundaries carry the correctness
Teams burned by "works with mocks, fails with Postgres"

Not for

Pure business logic — unit strategy with mocks is faster and sharper there
Full user journeys through the UI — that's the E2E Test Prompt

Use cases

Testing CRUD services against the real database layer
Verifying rollback actually rolls back — before production proves it doesn't
Catching constraint violations that surface as 500s instead of 400s

FAQ

Why generate integration tests against a real database instead of mocks?

The TEST STRATEGY treats the boundary as the subject, and mocking it away removes the very thing under test. The FAILURE SCENARIOS — constraint violations surfacing as the right application errors, a half-failed transaction leaving nothing partially committed, concurrent access to the same data — only exist against real components. Mocked tests structurally cannot see them.

What test framework does this prompt target and what does it enforce?

It targets xUnit and bakes in that framework's discipline. FRAMEWORK GUIDANCE requires [Theory] with [InlineData]/[MemberData] for parametrized cases, constructor/IDisposable for setup since xUnit makes a new instance per test, async tests returning async Task never async void, and precise asserts like Assert.NotNull. You run the generated file and review it.

Where does the prompt put behaviors it couldn't test from the code I pasted?

They land in two explicit lists after the tests. The ASSUMPTIONS heading collects every assumption made about unspecified behavior, and GAPS lists behaviors that couldn't be tested with the information given. Where intent is ambiguous, the prompt tests the most likely intent and flags the ambiguity rather than weakening an assertion to make a test pass.

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
Test the customer CRUD service against the real database layer.
Strategy: integration tests — real components together, the boundaries are the subject.
Generate tests only — do not modify the implementation.

CODE CONTEXT
[Paste the components under test here]

TEST STRATEGY
- Test real components together: the actual database, the actual service interaction — the boundary IS the subject.
- Verify data round-trips: what goes through the boundary comes back with meaning intact.
- Test transaction behavior: commits commit, rollbacks roll back, partial failures leave no debris.
- Each test owns its setup and teardown — tests must not depend on each other's data.

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:
- Database constraint violations surface as the right application errors
- A downstream service times out or returns an error mid-operation
- A transaction fails halfway — nothing is partially committed
- Two operations touch the same data concurrently

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: xUnit.
- Use [Theory] with [InlineData]/[MemberData] for parametrized cases instead of copy-pasted [Fact]s.
- Use constructor/IDisposable (or IClassFixture for shared expensive setup) — xUnit creates a new class instance per test.
- Async tests return async Task, never async void.
- Assert with Assert.* precisely — no bare Assert.True(result != null) where Assert.NotNull exists.

OUTPUT FORMAT
- Return one complete, runnable test file in xUnit.
- 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

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.

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

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

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.