We have now entered the era of the serverless function and we no longer have to worry about where or how our code runs. Someone else will do the worrying for us (for a nominal price) and we only have to concern ourselves with getting our functions to fulfill their destinies and become all they can be. Which raises some questions relating to our testing practices. Well, it raises other questions too, but for the purpose of this blog post that is the important one.
If you’re using Travis CI, Code Climate, or one of many other CI tools with Github, you’ve probably noticed the little checklist of items that shows just above the “merge” button when you open a pull request.
How we create Consumer Driven Contract tests to make sure our applications are working well with each other when using two frontend applications both of which are consuming common microservice APIs.
Imagine - you’re on a team writing an app that uses three different HTTP APIs, and you’ve decided to use consumer contracts to test your integrations.