Hello - question about consumer contacts and drift. It's quite easy for a consumer to define a contract, but how can we easily keep the contract up-to-date and not drift away from the actual consumption of the api. For example, a frontend may define a contract with an backend API, but use only a limited amount from either the request or even more likely the response. The initial contract definition is minimal as we dont want to overstate how we consume the API, however, as the frontend changes and consumes more fields from the backend's api response, how can we be deliberate enough to always make sure the contract is up-to-date. Are there any well defined patterns for this that someone can point out? In my case the frontend is React, but happy to review any pattern for this. Thanks in advance

The initial contract definition is minimal as we dont want to overstate how we consume the API, however, as the frontend changes and consumes more fields from the backend’s api response, how can we be deliberate enough to always make sure the contract is up-to-date.

If the consumer needs more fields from the response than they have defined in the contract, it should show up in the consumer test, as it should be a unit test of your API client. Any missing fields will not be present, and hopefully that should get picked up in that test. It’s harder to detect the reverse of this, obviously.

Correct, but is there a pattern to use to have consumer's implementation of the client be kept in sync with consumer tests?

I guess the answer is in how you would write a unit test. If the implementation is changing, and the unit test continues to pass either: 1. It was a bad unit test and would pass in most conditions 2. OR (hopefully) the unit test is only testing the observable behaviour that matters It should fail if its use of a downstream API usage changes, based on the observable behaviour of the unit under test, and the Pact test setup (i.e. the mock) wasn’t adjusted accordingly.