You just finished a patch for your API. Your unit tests pass. You have some end to end tests that cover most of the user facing features. You merge in your code and after a smooth deployment, all hell breaks loose. The microservice that the other team was developing doesn't understand what your new patch is sending as a response! What went wrong? This is a quick talk about contract based testing.
Microservices, they truly allow organizational agility and reduce the total cost of implementing a change. The separation of responsibilities and the cellular approach allows business requirements to be met without having to work on a huge code base. Services are now allowed to improve without being dependent on each other's functionalities. Or are they?
Although the decoupling of code has benefitted the development process it has, however, in turn, increased the need for better communication between teams and a way to do some sort of integration testing.
Some approaches to testing have been beneficial to catch issues early on. One such testing is what Swagger brings to the table. It allows one to not only to communicate how the API works by its documentation capabilities but to also allow an interface to test.
That being said, it seems to miss one type of testing approach that might be beneficial for cross-team development. The missing component is contract based testing wich will allow the two teams developing to test if their API's respond correctly in accordance to a consumer contract.
In this talk, I will be going briefly over what is consumer based contract testing, what it brings to the table for the development and maintenance of an API, and lastly, provide a very short example of such a test using Python.