Note: Because this is an ongoing series, viewers will not receive a certificate of completion.
Skill Level Intermediate
- [Instructor] When performing API testing it's expected to test the outcome of a request. For example, if I'm sending a post request to an end point, then I'm going to be creating something new on the application. Sending a valid post request to that end point will result in a new item being created. This is a functional API test. It focuses mainly on the outcome of that test, rather than the interaction between the two services involved. Contact testing looks deeper at this. It's a methodology for ensuring that two separate systems like microservices are compatible with each other. It captures the interactions that are exchanged between each service, storing them as a contract which can then be used to verify the both parties are adhering to it. Contract tests focus on the messages that flow between a consumer and a provider. While functional tests also ensure that the correct side effects have occurred. In the example, previously, a contract test would ensure that both the consumer and the provider had a shared and accurate understanding of the request and response required to create the new item. Whilst a functional test would ensure that when the post request was made, an item with the correct attributes was actually created in the underlying data store. A contract test does not check for these side effects. The pact foundation are probably the most well known for their tooling within the contract testing space. Their tools allow you to run a test, and then have the expected outputs captured as a pact or contract file. This file can then be used to assure that the contract between the two services is fulfilled. Contract testing allows you to ensure that the requirements between two or more services are being upheld. Even if you can't test that service in real time, having that contract allows you to create a mock of that service because you would already know all of it's expected outcomes.