API Mock and Stub Generation for UI Test Prompt Template

This prompt is for SDETs and automation engineers who need to decouple UI tests from live, flaky, or incomplete backend services. The core job-to-be-done is generating a functional mock server definition—complete with request matching, response templating, and stateful scenario sequences—that allows a UI test suite to run deterministically in CI/CD. The ideal user has a clear OpenAPI spec, a set of recorded API interactions, or a list of specific endpoints they need to stub. They are not looking for a generic 'how to mock' guide; they need a concrete, runnable stub configuration that handles the specific data shapes, error states, and sequencing their UI tests require.

You should use this prompt when the cost of live backend dependencies—slow test execution, environment contention, flaky network calls, or the inability to simulate error and edge cases—outweighs the value of end-to-end integration. It is particularly effective for generating stubs that simulate race conditions, slow responses, and specific error codes (e.g., 429, 503) that are hard to trigger on demand. The prompt expects structured inputs like an OpenAPI schema, a list of endpoints, or a HAR file. Without these, the generated mocks will be generic and require significant rework. Do not use this prompt to generate mock data for performance or load testing; those scenarios require a different scale of data generation and response timing.

A critical constraint is mock-to-real drift. The generated stubs are only as good as the contract they are built from. If the real API changes, the mocks become a source of false positives. The implementation harness must therefore include a contract drift detection step. Additionally, avoid over-mocking: if a UI test's primary purpose is to verify a complex backend integration, replacing that backend with a simple stub invalidates the test. Use this prompt for UI behavior tests, not for backend integration tests. Before generating stubs, confirm that the test's value is in the client-side logic, rendering, and user interaction, not in the backend's business logic.

After generating the stub configuration, your next step is to wire it into a mock server like WireMock, Mockoon, or a Playwright route interceptor. The prompt's output should be directly translatable into that server's configuration format. You must then validate the stubs by running the UI tests against them and checking for contract drift against the live API's specification. If the prompt generates a stateful scenario (e.g., 'first call returns empty, second returns data'), ensure your test harness can reset that state between test cases to prevent cross-test contamination.

This prompt template produces structured mock API definitions—including request matching rules, response templates, and stateful scenario sequences—from a combination of an API specification, UI test requirements, and the specific test scenarios that need controlled backend behavior. Copy the template below, replace the square-bracket placeholders with your actual inputs, and run it through your model. The output should be a ready-to-use mock server configuration or stub file that your test harness can consume directly.

textCopy
You are an SDET specialized in API mocking for UI test automation. Your task is to generate a complete mock server definition that enables UI tests to run without a live backend.

## INPUTS

### API Specification
[API_SPEC]

### UI Test Requirements
[TEST_REQUIREMENTS]

### Test Scenarios to Support
[TEST_SCENARIOS]

### Mock Framework
[FRAMEWORK: WireMock | Mock Service Worker | Playwright Route Interception | Cypress Intercept | json-server | Other]

### Output Format
[OUTPUT_FORMAT: JSON stub mappings | TypeScript handlers | YAML configuration | Other]

## CONSTRAINTS

- Generate request matching rules that are specific enough to avoid cross-test interference but flexible enough to handle dynamic path parameters, query strings, and request bodies.
- Include response templating for fields that must vary per request (timestamps, IDs, pagination tokens).
- For stateful scenarios, define sequences where the same endpoint returns different responses based on invocation count or prior state transitions.
- Cover at minimum: success responses, validation error responses (400/422), authentication error responses (401/403), not-found responses (404), and server error responses (500/503).
- Include configurable response delays to simulate network latency.
- Add comments explaining which test scenario each stub supports and any assumptions about request state.
- If the mock framework supports it, include response header configuration (Content-Type, CORS, caching directives).
- Flag any mock behavior that could mask real application bugs (e.g., always returning 200 when the real API would return an error under certain conditions).

## OUTPUT STRUCTURE

For each mock endpoint, provide:
1. **Request matcher**: HTTP method, URL pattern, headers, query parameters, body matchers
2. **Response definition**: Status code, headers, body template, fixed delay or distribution
3. **Scenario metadata**: Which test scenario(s) this stub supports, state dependencies, invocation count constraints
4. **Drift risk note**: What could change in the real API that would make this mock invalid

## ADDITIONAL INSTRUCTIONS

- If the API specification includes schema definitions, use them to generate response bodies that match the expected shape exactly.
- If the test scenarios require specific data values (e.g., a user with a known ID, an order in a specific state), hardcode those values in the response templates.
- For error scenarios, ensure the error response body matches the real API's error envelope structure.
- If [RISK_LEVEL] is "high" (e.g., financial transactions, healthcare data, authentication), add a note requiring human review before the mocks are committed to the test suite.
- Do not generate mocks for endpoints or scenarios not listed in [TEST_SCENARIOS].

Adaptation guidance: Replace [API_SPEC] with your OpenAPI document, GraphQL schema, or a plain-text description of the endpoints. [TEST_REQUIREMENTS] should describe what the UI test needs to verify—this constrains which response shapes matter. [TEST_SCENARIOS] is the critical input: list each test case with its expected API interactions, including error states and edge cases. Set [RISK_LEVEL] to "high" for regulated domains, which activates the human-review requirement in the output. After generation, validate that every mock endpoint maps to at least one test scenario and that error simulation coverage matches your test plan. If the output includes mocks for endpoints not referenced in your scenarios, remove them—they add maintenance cost without test value.

The API mock and stub generation prompt is designed to be called programmatically as part of a UI test authoring pipeline, not as a one-off chat interaction. The typical integration point is a CLI tool, a CI job, or an internal developer portal where an SDET provides an OpenAPI spec, a set of test scenarios, and a target mock framework (e.g., Mock Service Worker, WireMock, or Playwright route handlers). The application layer is responsible for assembling the prompt with the correct [OPENAPI_SPEC], [TEST_SCENARIOS], and [MOCK_FRAMEWORK] placeholders, then parsing the structured output into files that can be committed alongside the UI tests.

Before writing the generated stubs to disk, the harness must run a validation pass. The prompt template requests a specific [OUTPUT_SCHEMA]—typically a JSON array of stub definitions with fields for request matching, response templating, and scenario sequencing. Your harness should validate that every stub has a unique match rule, that response templates reference only fields present in the OpenAPI spec, and that stateful scenario sequences (e.g., 'first call returns 200, second call returns 429') are explicitly ordered. Reject any output that contains unresolved template variables, references to endpoints not in the provided spec, or mock logic that branches on headers the real API never sends. For high-risk test suites where a bad mock could mask a production defect, route the generated stubs to a human reviewer before they land in the shared test repository.

The most common production failure mode is contract drift: the generated mocks pass tests but no longer match the real API's behavior. To catch this, schedule a weekly drift-detection job that diffs the current OpenAPI spec against the spec version used when the mocks were generated. Flag any endpoint whose response schema, status codes, or required headers have changed. A second drift check should replay a sample of recent real API traffic against the mock definitions and log any request that would not match a stub—these represent untested API interactions. When drift is detected, re-run the prompt with the updated spec and the original test scenarios, then diff the new stubs against the existing ones to generate a reviewable change list. Do not auto-apply mock updates without human review if the test suite gates a release.

For model choice, prefer a model with strong JSON schema adherence and long-context handling, since OpenAPI specs can be large. If the spec exceeds the model's context window, preprocess it by extracting only the endpoints, schemas, and examples referenced by the provided test scenarios. Log every prompt invocation with the spec version, scenario list, and generated stub hash so you can trace which prompt run produced which mock file. If a generated stub causes a test to pass when it should fail, the trace lets you identify the exact prompt input that created the faulty mock and iterate on the template's [CONSTRAINTS] section to prevent recurrence.