Kube Cloud Pt6 | Contract Testingfull course
- Kube Cloud Pt6 | Contract Testing
- Kube Cloud Pt6 | Consumer Contract Tests for REST Endpoints
- Kube Cloud Pt6 | Provider Contract Test for REST Endpoints
- Kube Cloud Pt6 | Fulfill the Consumer Contract Test for REST Endpoint
- Kube Cloud Pt6 | Break the Contract from a Consumer Change
- Kube Cloud Pt6 | Synchronous Contract Testing Conclusion
Contract testing may be the most misunderstood and overlooked concept in distributed software development. As we’re developing microservices we’re going to need to do some service governance to make sure that service versions are compatible with each other. This can normally be managed with a conversation between teams developing in a monolith, since neither of their changes can go out without breaking the codebase. However, with microservice oriented teams operating at their own pace, service governance becomes much more important and tools (and accepted enterprise wide best practices) become much more important. Since each of the teams are delivering at their own pace with the feature sets that they need, they need to make sure that changes that are introduced are compatible with existing services that depend on them.
Part of the reason this is so often overlooked is that the concept involves two words that I find make engineers skin crawl
Testing: tests always seem to cause problems. Hopefully, my approach to testing through component tests focused on behavior can make testing much easier and lower the barrier to introducing new tests. Thankfully, contract tests are more like behavior tests than traditional unit tests.
Contracts: the term seems to imply some sort of process, which usually upsets developers
Finally, the frameworks that were used to build contract tests were complicated and often inadequate. This complexity often (rightfully) turned people off of them. However, I have found that pact‘s brand of contract testing not only lowers the barrier of entry by making tests easy, but their cloud hosted contract broker makes getting started easy and works well once you make changes to your build and deploy pipelines. This is a key and often overlooked component: your contract tests need to integrate into your build and deploy pipeline. This is because they’re doing the heavy lifting of service governance for you by checking to see if services are compatible before they get deployed together.
Setup a Pactflow account
Pactflow offers a cloud hosted pact broker that has a free trial account. Go ahead and setup the account
Once you create an account you should see the dashboard that looks like this:
Pactflow provides a broker which will be the place where contracts (defined by client contract unit tests) will be stored. The broker not only knows about all of the contracts and who the customer and providers are, but they can verify that the providers have “met the contract” through provider contract unit tests. The process of verifying that the contract has been met will be built into our pipelines and will either allow or halt the deployment of services that have validated or broken their contracts.
Lets start with writing some consumer contracts. We’ll be building the contract test from cloud-application to message-generator (synchronous REST call) as well as the contract test from message-repository to cloud-application (asynchronous messaging).