CRUD Lifecycle Test Sequence Prompt Template

This prompt is for API test engineers and SDETs who need to validate that a resource endpoint correctly implements the full create, read, update, and delete lifecycle. Use it when you have an OpenAPI spec or endpoint definition and need a sequence of test cases that verify state transitions, precondition enforcement, and data integrity across operations. The prompt produces a structured test sequence with explicit ordering, request payloads, expected responses, and state dependency tracking. It is designed for integration testing environments where tests must run in a specific order and share state.

The ideal user brings a complete endpoint definition—including supported methods, request schemas, authentication requirements, and known resource state transitions. The prompt works best when you can specify the resource's identity field (such as an id or slug) so the generated sequence can track state across operations. You should also provide any business rules that govern state transitions, such as 'a deleted resource cannot be updated' or 'status must be active before archiving.' Without these constraints, the model will generate generic CRUD sequences that may miss domain-specific lifecycle rules. The prompt assumes a working test environment with API access and does not generate environment setup scripts, authentication token acquisition steps, or load profiles.

Do not use this prompt for isolated unit tests that mock the API layer, performance benchmarking that requires concurrent load generation, or security penetration testing that probes for injection vulnerabilities or authentication bypass. It is not designed to generate contract tests between independent services or to validate event-driven side effects like webhook emissions or message queue publications. For those scenarios, use the Consumer-Driven Contract Test Prompt Template or the Webhook Signature Verification Test Prompt Template instead. If your API has complex authorization rules where different roles see different resource subsets, pair this prompt with the Security and Access Control Test Case Design prompt to ensure permission boundaries are tested alongside lifecycle operations.

Before running the generated test sequence, review the state dependency graph the prompt produces. Tests that depend on a created resource ID will fail if the create step is skipped or fails silently. Wire the sequence into a test runner that respects ordering and aborts on prerequisite failure. For high-risk APIs handling financial transactions, healthcare data, or personally identifiable information, add a human review step to validate that the generated assertions match your business rules before the sequence enters your CI pipeline. The prompt's output is a starting point—your domain expertise determines whether the lifecycle coverage is complete.

This prompt template is designed to be pasted directly into your AI system. It instructs the model to act as an API test architect and generate a complete, ordered test sequence for a resource's full lifecycle. The prompt uses square-bracket placeholders like [API_SPEC] and [RESOURCE_NAME] that you must replace with your specific details before execution. The generated test sequence will cover the standard Create, Read, Update, and Delete operations, but its primary value is in validating state transitions and preconditions between these steps, ensuring that a resource behaves correctly throughout its entire existence.

markdownCopy
You are an expert API test architect. Your task is to generate a comprehensive, end-to-end CRUD lifecycle test sequence for a specific API resource. The sequence must validate not only the individual operations but also the state transitions and preconditions between them.

**API Specification:**
[API_SPEC]

**Resource to Test:**
[RESOURCE_NAME]

**Required Test Sequence Structure:**
Generate a numbered, ordered list of test steps. Each step must include:
1.  **Step Action:** The exact API call to make (e.g., `POST /users`).
2.  **Request Payload:** A valid JSON body for the request, using realistic test data.
3.  **Preconditions:** The expected state of the resource before this step (e.g., "Resource must not exist").
4.  **Expected Status Code:** The primary HTTP status code for a successful outcome (e.g., `201 Created`).
5.  **Expected Response Body Validation:** Key fields and values to assert in the response (e.g., `body.id` is a non-null UUID, `body.name` equals the input name).
6.  **State Transition:** The new expected state of the resource after this step completes successfully (e.g., "Resource exists with status 'active'").

**Constraints:**
- The sequence must cover the full lifecycle: Create -> Read (verify creation) -> Update -> Read (verify update) -> Delete -> Read (verify deletion).
- Include a step to verify the resource's initial absence before creation.
- Include a step that attempts to read the resource after deletion to confirm it is no longer accessible.
- For the Update step, change at least two distinct fields.
- Use realistic but clearly fake test data (e.g., "Test User", "testuser@example.com").
- If the API spec defines any unique constraints or required fields, ensure the test data respects them.

**Output Format:**
Return the test sequence as a single JSON object with a `testSequence` array. Each element in the array should be an object with the keys `step`, `action`, `payload`, `preconditions`, `expectedStatus`, `expectedResponse`, and `stateTransition`.

To adapt this template, replace the [API_SPEC] placeholder with the relevant OpenAPI, GraphQL, or gRPC specification text. Replace [RESOURCE_NAME] with the specific resource you are targeting, such as users, orders, or articles. For high-risk domains like finance or healthcare, you should add a [CONSTRAINTS] section to enforce data privacy rules or compliance checks. After generating the sequence, always review it for logical ordering and completeness before wiring it into an automated test harness. A common failure mode is the model generating a valid sequence but using stale IDs between steps; ensure your harness captures and reuses the ID from the Create response in subsequent Read, Update, and Delete calls.

The CRUD lifecycle test sequence prompt is designed to be called from a test orchestration layer, not run manually in a chat interface. The application harness is responsible for providing the API specification, the target resource model, and any state-dependency rules. The prompt returns a structured test sequence that the harness must parse, validate, and then execute against the live system or a sandbox environment. Treat the prompt output as a test plan generator, not as an executor—the harness owns the actual HTTP calls, state tracking, and assertion logic.

Wire the prompt into a pipeline step that runs before test execution. The harness should supply [API_SPEC] as a resolved OpenAPI or GraphQL schema, [RESOURCE_MODEL] as the target entity definition with field constraints, and [STATE_RULES] describing valid state transitions and preconditions. After receiving the model response, validate the output against a strict JSON schema that requires an ordered array of test steps, each containing a stepId, operation (CREATE, READ, UPDATE, DELETE), endpoint, requestPayload, expectedStatus, expectedResponseSchema, and preconditions array. Reject any output that references endpoints not present in the input spec or that proposes invalid state transitions. Log the raw prompt, the validated output, and any schema violations for debugging. For high-risk APIs (payments, healthcare, identity), route the generated sequence to a human reviewer before execution, and never run destructive DELETE tests against production data without explicit approval.

After validation, the harness should execute the sequence in order, tracking the created resource ID and any state changes. If a step fails, halt the sequence, capture the failure context (step ID, actual vs. expected status, response body), and feed it back into a retry or diagnosis prompt. Do not blindly retry the entire sequence—use the failure to determine whether the test logic is wrong or the API behavior is wrong. Store execution results alongside the generated sequence for auditability. Avoid running lifecycle tests in shared environments where concurrent test runs can collide on resource identifiers; use unique prefixes or isolated tenants.