The Inverted Contract Testing

Or the right way to do contract testing on highly coupled software.

‘Is inverse contract testing about the client?’ — Prompted and edited by the author.

I always thought I clearly understood how contract testing worked. Many around me seemed to share this understanding and a high degree of confidence about it. It isn’t complicated, right? Contract testing is essentially about defining the API you wish to expose and creating a mechanism to ensure that this is consistently met. Simple as that, correct? Well, it turns out we could do it better.

Producer-Driven Contract Testing

Contract testing stands out as the most renowned approach in ensuring reliable API interactions. The very type I hinted at in the opening section. It’s about crafting a well-defined API and planning targeted tests to confirm adherence to its specifications.

Take the ‘Hello World’ service as an example. This service, by design, greets a specified name. Imagine you’re implementing contract testing for this scenario. Your tests might look something like this:

1. Service Description: 
   - Endpoint: `/helloWorld`
   - Method: `GET`
   - Query Parameter: `name` (string) - the name of the world to greet.
   - Response: A JSON object containing a greeting message.

2. Expected Behavior:
   - When the service receives a `name` parameter, it should…