OneOf/AnyOf Discriminator Test Prompt Template

Use this prompt when you need to generate a comprehensive test suite for API endpoints that accept or return polymorphic payloads defined with OpenAPI's oneOf/anyOf constructs and discriminator properties. This prompt is designed for integration test engineers and SDETs who must verify that an API correctly routes requests to the right variant, rejects invalid combinations, and returns proper error responses when discriminator values are missing, wrong, or ambiguous. The prompt assumes you have an OpenAPI specification snippet containing the polymorphic schema definition, including the discriminator property name, mapping table, and all variant schemas. It produces structured test cases with request payloads, expected status codes, expected response bodies, and validation assertions ready for automation frameworks.

The ideal input is a self-contained OpenAPI fragment that defines a discriminator object with its propertyName and mapping fields, along with the complete schemas for each variant referenced in the mapping. The prompt works best when variant schemas are distinct enough to produce meaningful routing differences—if variants differ only by optional fields, the test value diminishes. You should also provide any relevant endpoint context (method, path, success status codes) so the generated tests include realistic request routing. For high-risk domains like payments or identity where incorrect variant routing has security or financial implications, always include [RISK_LEVEL] as high to trigger additional negative test cases and human review markers in the output.

Do not use this prompt for simple enum validation, flat schema conformance, or non-discriminated union types; those require different test design strategies. This prompt is also not suitable for generating performance tests, fuzz tests, or authentication/authorization tests—it focuses exclusively on structural polymorphic routing correctness. If your API uses implicit polymorphism (guessing the variant from field shapes without a discriminator property), this prompt will not produce reliable tests; you need a schema shape matching approach instead. After generating the test suite, always validate that the discriminator values in the generated test payloads match the mapping table exactly, and run at least one positive and one negative case manually before integrating into CI.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a specialized API test engineer, generating a structured test suite from your polymorphic schema definition. The prompt uses square-bracket placeholders for all dynamic inputs, ensuring you can adapt it to any OpenAPI specification, GraphQL schema, or custom contract that uses discriminators for variant selection.

textCopy
You are a senior API test engineer specializing in polymorphic schema validation. Your task is to generate a comprehensive test suite for the OneOf/AnyOf discriminator logic defined in the provided schema.

# SCHEMA DEFINITION
[SCHEMA_DEFINITION]

# OUTPUT SCHEMA
You must output a single JSON object with the following structure:
{
  "test_suite_name": "string",
  "discriminator_property": "string",
  "test_cases": [
    {
      "test_id": "string",
      "test_name": "string",
      "category": "positive_variant_routing | negative_invalid_discriminator | negative_missing_discriminator | negative_invalid_combination | edge_case",
      "description": "string",
      "input_payload": {},
      "expected_status_code": 200 | 400 | 422 | 500,
      "expected_variant_routed_to": "string | null",
      "expected_error_message_contains": "string | null",
      "risk_level": "low | medium | high"
    }
  ],
  "coverage_summary": {
    "total_variants": "number",
    "variants_tested": "number",
    "untested_variants": ["string"],
    "discriminator_values_tested": ["string"]
  }
}

# CONSTRAINTS
[CONSTRAINTS]

# EXAMPLES
[EXAMPLES]

# INSTRUCTIONS
1. Parse the SCHEMA_DEFINITION to identify the discriminator property and all possible variant mappings.
2. For each variant, generate a positive test case that sends a valid payload with the correct discriminator value and variant-specific fields.
3. Generate negative test cases for: an invalid discriminator value, a missing discriminator property, and a payload that mixes fields from multiple variants.
4. Include edge cases such as empty objects, null discriminator values, and extra unexpected properties.
5. Ensure the output strictly conforms to the OUTPUT SCHEMA. Do not include any text outside the JSON object.

To adapt this template, replace [SCHEMA_DEFINITION] with the raw JSON or YAML of your OpenAPI schema component, focusing on the oneOf or anyOf block and its discriminator mapping. The [CONSTRAINTS] placeholder should be filled with any specific rules, such as 'Do not test deprecated variants' or 'Only generate tests for the Pet schema'. Use the [EXAMPLES] placeholder to provide one or two correct input-output pairs, which dramatically improves the model's adherence to your exact output schema and test-naming conventions. For high-risk financial or healthcare APIs, ensure a human reviews the generated input_payload objects before execution to prevent accidental data corruption.

After pasting the prompt, validate the model's output against the defined JSON schema before feeding test cases into your automation framework. A common failure mode is the model generating a discriminator_property that doesn't match the schema's actual propertyName. Always run a quick diff check. The next section, 'Implementation Harness', will show you how to wire this prompt into an automated pipeline with retry logic and schema validation.

The OneOf/AnyOf Discriminator Test Prompt Template is designed to be called programmatically, not used as a one-off chat interaction. In a production harness, you feed it a JSON Schema or OpenAPI schema fragment containing oneOf/anyOf with discriminator mappings, and it returns a structured test suite. The harness must validate that the output contains the expected test case fields: discriminatorProperty, mappingCoverage (all variants tested), validVariantTests, invalidCombinationTests, and errorExpectationTests. Without this validation, you risk shipping test suites that miss unmapped variants or fail to verify that the API rejects invalid discriminator values.

Wire the prompt into a test generation service with the following pipeline: (1) Schema Preprocessing — extract the oneOf/anyOf block and its discriminator definition from the full spec, including the mapping object and each variant's $ref or inline schema. Pass only the relevant fragment to keep context tight. (2) Prompt Execution — call the model with the preprocessed schema as [SCHEMA_FRAGMENT], setting [CONSTRAINTS] to require exhaustive mapping coverage and explicit error test cases. Use a model that supports structured output (JSON mode or function calling) and set response_format to enforce the output schema. (3) Output Validation — before accepting the result, run automated checks: confirm that every key in the discriminator mapping has at least one valid variant test and one invalid combination test; verify that errorExpectationTests cover missing discriminator, unknown discriminator value, and discriminator with mismatched variant shape; check that all test cases include expectedStatusCode and assertions arrays. (4) Retry with Error Feedback — if validation fails, construct a retry prompt that includes the original schema, the partial output, and a specific error message like 'Missing test case for discriminator value "credit_card" in mappingCoverage.' Limit retries to 2 attempts before flagging for human review.

For integration into CI/CD, store the generated test suite as a versioned artifact alongside the schema version it was generated from. When the schema changes, re-run generation and diff the test suites to detect coverage regressions. Avoid running this prompt against entire multi-kilobyte OpenAPI specs without preprocessing — the model will lose precision on discriminator edge cases when context is diluted. If your API uses nested discriminators or polymorphic arrays, split them into separate generation calls and merge the results. For high-risk payment or identity APIs, add a human review step before the generated tests are committed to the test repository, especially for invalidCombinationTests that might expose unintended error-handling gaps.