Consumer-Driven Contract Test Case Prompt

This prompt is designed for backend and QA engineers who need to rapidly generate provider-side verification tests from consumer contract definitions in Pact or similar CDC frameworks. The core job-to-be-done is converting a structured contract file—typically a Pact interaction JSON—into a ready-to-run test stub that validates request matching, response structure, and provider state setup. You should use this when you have consumer contract files checked into a repository and need to bootstrap provider tests before deployment, or when you want to validate that a provider implementation satisfies all known consumer expectations without manually translating each interaction into test code. The ideal user has access to the contract file, understands the provider's state setup requirements, and needs executable test scaffolding that can be integrated into a CI pipeline.

The prompt requires a structured interaction definition as input. This means you must provide a valid Pact interaction JSON block or an equivalent contract specification that includes the request method, path, headers, query parameters, body, and the expected response shape. The prompt also expects a description of the provider state required for the interaction to be valid. Do not use this prompt for generating consumer-side tests, for contracts defined only in prose without structured interaction definitions, or when provider state setup requires access to production data that cannot be described in a fixture. The output is a test stub, not a production test suite—it requires human review to verify that state setup fixtures are safe, that response matchers are appropriately strict or lenient, and that the generated test correctly integrates with your test runner and assertion library.

Before using this prompt, ensure you have the contract file available and understand which provider states are required. After generating the test stub, review the state setup code for any assumptions about database state, third-party service availability, or environment variables that may not hold in your test environment. Wire the generated test into your provider's test suite and run it against a locally running provider instance to confirm it passes before merging. Avoid using this prompt for interactions that involve complex authentication flows, time-sensitive tokens, or non-deterministic response fields without adding custom matchers—the generated stub will need manual adjustment for these cases.

This prompt template takes a consumer-driven contract definition—typically a Pact interaction JSON or a structured description of the expected request and response—and produces executable provider verification test stubs. The output includes request matching logic, response validation assertions, and provider state setup requirements. Use it when you have a consumer contract and need to generate the provider-side tests that prove the provider satisfies that contract.

textCopy
You are a contract test engineer specializing in consumer-driven contract testing with Pact.

Generate provider verification test cases from the following consumer contract definition.

## CONSUMER CONTRACT
[CONSUMER_CONTRACT]

## TEST FRAMEWORK
Generate tests using: [TEST_FRAMEWORK]

## LANGUAGE
Write test code in: [LANGUAGE]

## PROVIDER STATE HANDLING
Provider state setup mechanism: [STATE_SETUP_MECHANISM]

## OUTPUT REQUIREMENTS
For each interaction in the consumer contract, produce:

1. **Test function name**: Descriptive name following [NAMING_CONVENTION]
2. **Provider state setup**: Code or configuration to establish the required provider state before the test runs, including any fixture data needed
3. **Request matching**: Assertions that verify the provider receives the expected HTTP method, path, query parameters, headers, and request body as defined in the contract
4. **Response validation**: Assertions that verify the provider returns the expected status code, headers, and response body structure and values as defined in the contract
5. **Edge case handling**: Additional assertions for optional fields, nullable fields, and array boundaries where the contract implies them
6. **Teardown notes**: Comments indicating any state cleanup required after the test

## CONSTRAINTS
- Use the exact matcher types from the contract (e.g., `term`, `like`, `eachLike`) and translate them into framework-appropriate assertions
- For regex matchers in the contract, generate both a matching-value test and a boundary-value test
- Flag any interactions where the provider state description is ambiguous or missing with a `# TODO: Clarify provider state` comment
- Do not generate tests for interactions marked as `pending` in the contract
- Include imports and test framework boilerplate only if [INCLUDE_BOILERPLATE] is true

## OUTPUT FORMAT
Return the test cases as a single code block with the language tag matching [LANGUAGE]. Precede the code block with a summary table listing each interaction ID, the provider state required, and any risks or ambiguities found.

## EXAMPLES
[EXAMPLES]

Adapt this template by replacing each square-bracket placeholder with your concrete values. For [CONSUMER_CONTRACT], paste the full Pact interaction JSON or a structured YAML description of the expected request and response. For [TEST_FRAMEWORK], specify the exact test runner and assertion library (e.g., Jest with @pact-foundation/pact, pytest with pact-python, JUnit 5 with Pact JVM). For [STATE_SETUP_MECHANISM], describe how your provider sets up state—whether through API endpoints, database fixtures, or mock services—so the generated code matches your actual test infrastructure. The [EXAMPLES] placeholder should contain one or two complete interaction-to-test mappings from your own codebase to ground the model in your team's conventions. Start with a single interaction and validate the output against your provider before scaling to a full contract file.

Integrating the Consumer-Driven Contract Test Case Prompt into a development workflow requires treating it as a code generation step with strict validation gates. The prompt accepts a Pact contract file (or equivalent CDC definition) and outputs executable provider verification test stubs. Because the output is code that will run in CI, the harness must validate syntax, enforce provider state fixture completeness, and ensure the generated tests actually exercise the contract's interaction expectations before merging.

The implementation harness should follow a three-stage pipeline: generation, validation, and fixture resolution. First, feed the consumer contract JSON into the prompt along with your target test framework ([TEST_FRAMEWORK]) and language ([LANGUAGE]). The model outputs test code stubs. Immediately pipe this output through a syntax validator (e.g., pytest --collect-only for Python, jest --dry-run for TypeScript) and reject any output that fails to parse. Second, extract the list of required provider states from the generated tests and cross-reference against your provider's state setup catalog. Any state referenced in a test but missing from the catalog must block the pipeline and surface a missing-fixture error. Third, run the generated tests against a real provider instance with known state fixtures. Tests that fail due to incorrect request matching or response validation logic—not fixture unavailability—indicate a prompt failure that should be logged for evaluation.

For model choice, prefer a model with strong code generation capabilities and strict schema adherence (e.g., Claude 3.5 Sonnet or GPT-4o with structured outputs enabled). Set temperature to 0 or near-zero to minimize variation in generated test logic. Implement a retry loop with a maximum of two retries: if validation fails, append the validator error message to the prompt context and re-invoke. If the second attempt also fails, escalate to a human reviewer with the contract, the failed output, and the validation error. Log every generation attempt—including contract version, prompt version, model, generated test count, validation pass/fail, and any fixture gaps—to enable regression testing when the prompt or contract format evolves. Avoid wiring this directly into a merge gate without first running a shadow mode that generates tests alongside existing verification suites for at least two sprint cycles to measure false-positive and false-negative rates.