What this prompt does
This prompt builds an integration test suite for an API. You specify [api_type] (REST or GraphQL), the [framework], and a list of [endpoints], and for each endpoint the AI generates a battery of tests: authentication cases (valid, expired, missing token), happy path, validation errors, authorization checks, database-state assertions, response-structure validation against a [schema_format] schema, pagination and filtering where relevant, and rate-limit behaviour. It uses [test_framework] with your [db_strategy].
The structure works because it tests at the seam where most real bugs live — the boundary between client input and persisted state. By requiring auth, validation, authorization, and database assertions for every endpoint, the prompt catches the authorization and boundary defects that are expensive to find in production. The [db_strategy] variable ensures tests start from a known state, and schema validation against [schema_format] keeps response contracts honest.
When to use it
- You run an API-first backend and want auth, validation, and DB state locked down before launch.
- You are adding new
[endpoints]and want them covered consistently. - You need authorization and role-based access tested, not just happy paths.
- You want responses validated against your
[schema_format]contract. - You need database-state assertions confirming records are actually created, updated, or deleted.
- You want pagination, filtering, and rate-limit behaviour exercised.
Example output
You get a [test_framework] test suite organised by endpoint. Each [endpoints] entry gets multiple test methods — auth variants, valid and invalid inputs, authorization checks, and assertions on database rows — plus shared helpers for authentication and factory data. With a [db_strategy] like RefreshDatabase, each test runs against a clean schema.
Pro tips
- List
[endpoints]with their HTTP verbs and paths exactly; precise input yields precise tests. - Match
[db_strategy]to your project so tests reset state the way the rest of your suite expects. - Make sure the
[framework]and[test_framework]pairing is real — Laravel with PHPUnit, Express with Jest — or generated helpers will not run. - Provide your
[schema_format]spec if you have one; structure assertions are far stronger when grounded in a real OpenAPI or JSON Schema definition. - Verify the authorization tests use roles that actually exist in your app.
- Run the suite against a seeded test database first to catch factory mismatches early.
