chapter seven

7 API conformance: schema testing

 

This chapter covers

  • Writing code-based schema tests
  • Auto-generating API schema tests
  • Using a validation proxy for schema tests

In the last chapter, I looked at how generating the OpenAPI definition (and the associated API reference) from the API service helps ensure that the OpenAPI definition conforms to the behavior of the service. But it may not be possible to generate the OpenAPI definition due to technical limitations in legacy API services. And even if you can generate the OpenAPI definition from the API service, the behavior of the service under exploratory testing may reveal surprising behavior from the application, which may not be captured by the OpenAPI definition. For example, a bad request with illegal characters can cause the backend application server to return an error before the request is processed by your controller's error-handling logic. And so, an OpenAPI definition generated based on the controller code may not cover this case.

So, it is still valuable to have an additional layer of verification to check that the published API reference matches the API behavior. One way to do this is with schema testing using the OpenAPI definition as the definition of the API schema. In this chapter, I discuss three techniques for writing OpenAPI schema tests. These are code-based schema tests, generated schema tests, and using a validation proxy.

7.1 Schema tests

7.2 Code-based schema tests

7.2.1 Writing end-to-end schema tests

7.2.2 Writing controller schema tests

7.3 Things to consider with code-based schema tests

7.4 Generated schema tests

7.4.1 Using Schemathesis for schema testing

7.4.2 Using Portman for schema testing

7.5 Using a validating proxy for consistency

7.6 Comparing API conformance approaches

7.7 How schema tests are different from consumer-driven contract tests

7.8 Summary