We have microservices that are exposed by a JSONAPI REST interface, and the question of whether to add contract testing came up. As we control both the producers and consumers of these APIs, a tool like Pact seemed like a good choice.
However, the more I investigate it, the more I am convinced that contract testing with services that already adhere to a standard like JSONAPI is overkill. But I wanted to share these thoughts with the community to see if I am missing something.
The Pact documentation provides a 5 minute guide to get you started with contract testing. It begins by writing a client test to verify the interaction with the server.
The result of running this test is a contract that is used to replays the network requests against the server, thus verifying the consumer and producer agree on how they will interact.
These contracts are concerned with the HTTP interactions between a client and server. The client defines the request it expects to make, capturing things like the paths, query params, headers, request and response bodies. The server then verifies its ability to satisfy these requests.
What I immediately notice though is that any service adhering to JSONAPI does not require a client to express its desired interactions. The paths, headers, query params, request and response bodies are all clearly documented by the JSONAPI spec.
In fact, simple unit tests on the producer that verify the API it exposes is JSONAPI compliant makes consumer/producer contract testing almost completely irrelevant. The JSONAPI spec clearly defines how producers and consumers interact, and producers and consumers can independently verify their compliance without much knowledge of one another.
There are a few things about contract testing that I do like. Contract tests allow a producer to know what parts of its interface it can remove without impacting a client, making deprecation easy. Contract tests also provide concrete examples of interactions that JSONAPI doesn’t provide hard and fast rules for, such as paging or filtering.
That said, there are better solutions that provide these same benefits. Logging interactions made to a live server allows producers to identify unused API calls, while JSONAPI profiles and extensions allow for concrete implementation of features like paging and filtering.
I’m struggling to think of a scenario where contract testing services that adhere to a spec like JSONAPI provides enough benefit to be worth the trouble. While I certainly understand the benefit of contract testing services that have grown their API organically over the years, anyone who has had the luxury of implementing JSONAPI from the outset will gain little from contract testing.
Am I missing something here, or is contract testing really unnecessary for anyone implementing JSONAPI?