End-to-end testing verifies an API response against its published schema while exercising the complete deployed path, including the API gateway, service, and dependent components. It is useful when external or public APIs cannot use consumer-driven contract tests, but it runs more slowly and is harder to debug, maintain, and scale than controller-level testing with mocked dependencies. section 7.2 section 7.8
A practical end-to-end schema test follows this workflow:
- Start the Kong API gateway and the API service using the platform-specific scripts. section 7.2.1
- Use Rest Assured to send a GET request to the product-catalog endpoint, provide an API key, and attach an OpenAPI validation filter. section 7.2.1
- Assert the expected HTTP status and validate the complete response against the selected OpenAPI YAML definition. section 7.2.1
- Maintain tests as endpoints and happy- and sad-path responses grow, or generate scenarios from the OpenAPI definition with tools such as Schemathesis or Portman. section 7.3 section 7.8
Detecting undocumented response fields
A product-catalog request initially validates against product-catalog-v1-0.oas.yaml but fails because the response contains numberOfReviews and reviewRating while additionalProperties is false. Updating the validation filter to product-catalog-v1-1.oas.yaml, which defines those properties, makes the test pass. Keeping additionalProperties false also helps detect unexpected data. section 7.2.1
Figure 7.2 A schema test can be against the entire stack or just at the controller level of an API service.
Compare schema validation at the entire deployed stack with validation at the controller level, where dependent systems are mocked. section 7.2
