AI Prompts for Writing Integration Tests

Before: The Weak Prompt

Studies on software testing ROI consistently show that integration bugs cost 10–15× more to fix in production than in testing. Yet most development teams spend 80% of their testing effort on unit tests that cover individual functions in isolation — and only discover integration failures when the whole system is assembled.

Integration tests are hard to write well. And when developers turn to AI for help, they typically produce this:

Write integration tests for my user registration API endpoint.

POST /api/users
Body: { "email": "test@example.com", "password": "secret123" }

The AI generates a test that posts to the endpoint and checks for a 200 response. Maybe checks the response body has an

id

That test tells you the endpoint responds. It doesn't tell you whether the user actually landed in the database, whether the welcome email queued, whether the password was hashed before storage, or whether registering the same email twice returns the right error.

Why It Fails

Integration tests should verify behavior across system boundaries — database writes, queue messages, external service calls, state changes that span multiple layers. A prompt that just says "write integration tests" gets you API surface tests, which are barely above smoke tests in diagnostic value.

Three specific failures in the basic prompt:

No system boundary specification. "User registration" touches at least three systems: the database, the email queue, and possibly a third-party identity provider. Without naming those boundaries, the AI only tests one of them.

No failure scenario requirement. Happy-path-only integration tests are the testing equivalent of testing only that the car starts — not that it stops. The most valuable integration tests cover what happens when one component fails.

No state verification. Checking the HTTP response tells you the API returned something. Checking that the database row exists with the correct values tells you the system actually did the work.

⚠️ Common mistake: Treating integration tests as "unit tests that happen to call an actual endpoint." True integration tests verify the full chain of effects a request produces — not just the final HTTP response code.

After: The Improved Prompt

You are a QA engineer writing integration tests for a Node.js/Express user registration endpoint.

System components involved:
- REST API (Express)
- PostgreSQL database (users table)
- Redis-based job queue (email welcome job)
- bcrypt for password hashing

Write a complete integration test suite using Jest + Supertest. Include tests for:

1. Happy path: POST with valid email/password
   - Verify: 201 response with user ID
   - Verify: user row exists in DB with hashed password (not plaintext)
   - Verify: welcome email job added to queue

2. Duplicate email: POST with already-registered email
   - Verify: 409 response with specific error message
   - Verify: no duplicate row created in DB

3. Invalid inputs: missing email, missing password, malformed email
   - Verify: 400 response for each with descriptive error message

4. Database failure simulation: mock DB to throw on insert
   - Verify: 500 response
   - Verify: no queue job created (no partial side effects)

Test setup requirements:
- Use a real test database (not mocked)
- Reset user table before each test
- Mock only the email queue (not the DB)
- Include beforeAll/afterAll for DB connection lifecycle

Language: TypeScript

What this does: It maps out every system boundary and explicitly requires tests for failure scenarios and side-effect verification — the two things that make integration tests actually useful in production debugging.

⚡ Pro tip: The "mock only the email queue" instruction is deliberate. Integration tests should use real databases whenever possible — mocked databases test your mock, not your database interactions. Only mock external services you can't control or run locally.

Breaking Down Each Element

System components list — naming every downstream system forces comprehensive boundary coverage. Without it, the AI picks the most obvious one (the HTTP response) and stops.

Side-effect verification — "Verify: welcome email job added to queue" is the kind of assertion most developers skip. It's also exactly the kind of failure that causes customer complaints ("I never got my welcome email") that don't show up in error logs.

Database failure simulation — testing what happens when a dependency fails tells you whether your system fails cleanly or creates partial state. Partial state — user exists in DB but queue job wasn't created — is one of the hardest production scenarios to recover from.

Real database over mock — this is the highest-use instruction in the prompt. Mocked databases often hide ORM quirks, constraint violations, and transaction behavior that only surface with a real database engine.

⚡ Pro tip: Add "include a test that verifies the operation is idempotent where applicable" to any integration test prompt for write operations. Idempotency testing catches bugs that only appear when network retries cause duplicate requests — a real-world failure mode that unit tests never simulate.

Variations for Different Contexts

For microservices integration tests:

Write integration tests for the interaction between Service A (order service) and Service B (inventory service). Test: successful reservation, reservation with insufficient stock, and Service B timeout. Use WireMock or nock to simulate Service B responses. Verify both the response to the caller and any events published to the message bus.

What this does: Tests the contract between services, not just one service in isolation. Contract testing is the most valuable and least-practiced form of integration testing.

For database migration testing:

Write integration tests that verify this database migration applies correctly. Test: migration runs without errors on empty table, migration runs on table with existing data (verify data integrity), and rollback restores original schema. Use a test database and run actual migration scripts.

What this does: Migration tests prevent the "works in staging, destroys production data" migration failure — one of the highest-cost deployment incidents in web development.

Save and Reuse This

The prompt above is a template. Before reusing it, update: the technology stack, the system components involved, and the specific side effects your operation produces. The structure — happy path, error cases, failure simulation, side-effect verification — stays constant.

Save your team's tuned version in a prompt library. PromptABCD works well for this — it keeps your ai prompts integration tests accessible without living in someone's personal notes. The next time a new endpoint ships, the integration test prompt is ready to go.

Testing Integration Tests Themselves

One meta-challenge with integration tests: how do you know your integration tests are actually testing integration? A common trap is an integration test that mocks so many components it's effectively a unit test wearing integration test clothing.

A useful prompt for auditing your test suite:

Review this integration test and identify: which components are real versus mocked, whether any mocked component is a critical integration boundary, and whether the test would still fail if the real component behaved differently from the mock. Flag any test that is effectively a unit test mislabeled as an integration test.

Test code: [paste]
System components involved: [list real components in production]

What this does: Catches the gradual mock-drift that makes integration test suites lose their value over time. Teams often start with real components and add mocks for speed, eventually hollowing out the integration coverage.

⚡ Pro tip: Set a team standard for what real means in integration tests. "Real database, real file system, mocked external HTTP calls" is a reasonable baseline. Write it down. AI prompts that include "according to our integration test standard: [paste standard]" produce tests that match your team's conventions without constant review feedback.

Organizing Integration Tests in CI/CD

Integration tests run slower than unit tests. That's expected — they're doing more work. But slow tests that block every commit create pressure to skip them, which defeats their purpose.

A prompt for CI/CD integration test strategy:

I have these integration tests that take a combined 4 minutes to run. Design a CI/CD strategy that: runs fast unit tests on every commit, runs integration tests on pull requests before merge, and runs full integration test suites nightly. Suggest how to tag and organize tests in pytest so different CI stages run different subsets.

Current test files: [list]
CI platform: [GitHub Actions / GitLab CI / Jenkins]

What this does: Produces a concrete test organization plan with pytest markers and CI configuration — faster to implement than designing it from scratch and more likely to be actually adopted by the team.

Finally, track integration test failures separately from unit test failures in your CI dashboard. Integration failures that are consistently flaky — passing sometimes, failing sometimes — indicate real infrastructure instability, not test quality issues. Separating the metrics tells you whether you have a test problem or an infrastructure problem, which are very different things to fix. ⚡ Pro tip: For microservices, ask specifically for consumer-driven contract tests alongside integration tests: 'Write a Pact consumer contract for this interaction between Service A and Service B. The contract should define: what Service A expects from Service B, and fail if Service B's response changes in a breaking way.' Contract tests catch breaking changes before they reach integration environments.

Flaky integration tests that your team starts ignoring are worse than no tests — they erode trust in the whole test suite. Investigate flakiness immediately; it's almost always a timing issue or a shared state problem, both of which are fixable with targeted prompt-driven refactoring.