Member-only story
When Is The Inverted Contract Testing Really Necessary?
The when and the how of protecting your software against external changes.
In my previous article, I discussed the inverted contract testing, which involves testing in a manner contrary to what we usually expect. Normally, contract testing implies that the service creates its own definitions and tests. However, we can go a step further and have the client create tests for the service. But when to do that?
The why is straightforward.
If we are developing a client, and we have no control over the service, we’re at risk. Even if we don’t change anything on our end, changes in the service can still break our application.
How do we prevent this?
As the previous article says, by adding the client’s relevant tests into the service’s own code repository. That safeguards ourselves from breaking changes. Any dangerous change by the service will break its own CI, forcing a dialogue and agreement on a solution with us. We are protected.
