Consumer-Driven Contract Testing Prompt Template

This prompt is designed for the contract testing phase of your CI pipeline, specifically after consumer contracts are published to a Pact Broker and before a provider build is deployed. The primary job-to-be-done is to transform a set of consumer-defined interactions—including HTTP methods, paths, request bodies, and expected response shapes—into structured, executable provider verification artifacts. The ideal user is a QA engineer or backend developer who already has access to consumer interaction definitions and needs to produce Pact-compatible provider state descriptions, test setup logic, and verification assertions without manually translating each interaction into boilerplate test code.

Use this prompt when you have a well-defined set of consumer expectations and need to generate the provider-side verification logic that proves the provider meets those expectations. The required context includes the consumer interaction definitions (method, path, headers, request body, expected response status and body), any known provider state requirements (e.g., 'a user with ID 123 exists'), and the target testing framework (e.g., Pact-JVM, Pact-JS, Pact-Net). The prompt is not suitable for generating consumer contracts from scratch, for end-to-end integration tests that bypass contract validation, or for scenarios where consumer interactions have not yet been finalized and published. It also should not be used as a replacement for understanding Pact's provider verification lifecycle—the generated output still requires human review to ensure state setup is feasible and assertions are correct.

Before using this prompt, ensure your consumer contracts are published and versioned. The prompt assumes you can provide the raw interaction JSON or a structured summary. After generating the provider verification artifacts, you must wire them into your provider's test suite, implement the actual state setup logic (e.g., database fixtures, API calls), and run the verification against a real provider instance. Avoid treating the generated output as production-ready without first validating that provider states are isolated, teardown logic is correct, and assertions cover both happy-path and error-response scenarios.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to generate provider-side verification tests from a set of consumer interaction expectations. The output is structured for direct use with Pact or similar consumer-driven contract testing frameworks. Replace every square-bracket placeholder with your specific consumer interactions, provider context, and output requirements before execution.

codeCopy
You are a QA automation engineer specializing in consumer-driven contract testing. Your task is to generate a set of provider verification tests based on the consumer expectations provided below.

## CONSUMER INTERACTIONS
[CONSUMER_INTERACTIONS]

## PROVIDER CONTEXT
- Provider Name: [PROVIDER_NAME]
- Provider Base URL: [PROVIDER_BASE_URL]
- Provider State Setup Instructions: [PROVIDER_STATE_SETUP]

## OUTPUT SCHEMA
Generate a JSON object with the following structure:
{
  "provider": {
    "name": "string"
  },
  "interactions": [
    {
      "description": "string",
      "providerState": "string",
      "request": {
        "method": "string",
        "path": "string",
        "headers": { "key": "value" },
        "body": {},
        "query": "string"
      },
      "response": {
        "status": "integer",
        "headers": { "key": "value" },
        "body": {}
      }
    }
  ],
  "metadata": {
    "pactSpecification": {
      "version": "3.0.0"
    }
  }
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Analyze each consumer interaction to identify the exact request the consumer expects to make.
2. For each interaction, define a `providerState` that describes the exact data and conditions the provider must have before the request is made. Ensure states are isolated and do not leak data between tests.
3. Generate the complete Pact-compatible interaction object, including request matching rules if specified in the constraints.
4. If a consumer interaction is ambiguous or missing critical details (e.g., HTTP method, path), flag it in a `warnings` array within the metadata object instead of guessing.
5. After generating the interactions, perform a self-check: review each interaction for missing edge cases (e.g., empty bodies, missing headers, non-2xx responses) and append any missing test scenarios as additional interactions with a clear note in the description.

To adapt this template, start by populating [CONSUMER_INTERACTIONS] with the raw expectations from your consumer tests, often extracted from a Pact file or a mock service log. The [PROVIDER_STATE_SETUP] placeholder should contain instructions for your provider's data setup hooks, such as 'a user with ID 123 exists' or 'the inventory service is empty.' Use the [CONSTRAINTS] block to enforce strict matching rules, like requiring exact header matching or specifying body matchers for dynamic fields. The [EXAMPLES] block is critical for teaching the model the correct format; include at least one well-formed interaction with a non-trivial provider state. After generation, always validate the output against the official Pact specification schema and run the generated tests in a sandbox provider environment to catch state leakage or incorrect matching logic before integrating into your CI pipeline.

This prompt is designed to be embedded in a CI pipeline that runs whenever a consumer contract is updated or a provider build is triggered. The harness should treat the prompt as a generation step whose output is validated, transformed, and fed into a Pact-compatible verification framework. Do not treat the raw LLM output as the final test artifact—always run it through a structural validator before execution.

The implementation flow should follow these stages: (1) Input assembly—collect the consumer interaction specification, provider state catalog, and any existing provider test fixtures into the [CONSUMER_SPEC], [PROVIDER_STATE_CATALOG], and [EXISTING_TESTS] placeholders. (2) Prompt execution—call the model with a low temperature (0.0–0.2) to maximize deterministic output. (3) Structural validation—parse the output as JSON and validate against a Pact interaction schema (fields: description, providerState, request.method, request.path, request.headers, request.body, response.status, response.headers, response.body, response.matchingRules). Reject any output missing required fields or containing malformed matching rules. (4) Semantic validation—run eval checks: verify that every consumer expectation has a corresponding provider state, confirm no hardcoded environment values leak into the contract, and check that edge cases (empty bodies, null fields, unexpected status codes) are covered. (5) Artifact generation—write the validated interactions into a Pact JSON file in the provider's test directory. (6) Verification execution—run the provider verification task against the generated contract. Fail the pipeline if verification fails or if the generated contract is structurally invalid.

For retry logic, implement a single retry with a different temperature (0.3) if structural validation fails on the first attempt. If the retry also fails, log the raw output and the validation errors, then fail the pipeline with a clear message indicating the prompt could not produce a valid contract. Do not retry more than once—malformed output on two attempts signals a prompt or input problem that requires human investigation. For logging, capture the prompt version, model version, input spec hash, output contract hash, validation pass/fail status, and any eval failures. This trace is essential for debugging contract drift and prompt regressions over time.

Model choice matters here. Use a model with strong JSON generation and instruction-following capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or older models that struggle with nested JSON structures and precise field constraints. If using an open-weight model, validate that it can reliably produce Pact-compatible matching rules before deploying this prompt into CI. Human review is required when the generated contract introduces new provider states not present in the [PROVIDER_STATE_CATALOG]—these represent untested assumptions about provider behavior and must be reviewed by the provider team before verification can proceed. Add a review gate that blocks the pipeline until the new states are approved and implemented.

What to avoid: Do not use this prompt to generate contracts for providers you do not control. Consumer-driven contracts assume collaboration between consumer and provider teams. Do not skip the structural validator—LLM output format drift is the most common failure mode in production. Do not run verification against production environments; always use dedicated test or staging provider instances. Finally, do not treat a passing verification as proof of correctness—it only confirms that the provider satisfies the consumer's stated expectations, not that those expectations are complete or correct.