API is an important part of any web application, it helps the consumer to get the data or any other services very easily, but many times when we are trying to connect the consumer of an API and the provider at that time in order to get the confidence that everything will work fine now and also in production,we need a guarantee that it won’t fail. This is where the API testing part comes into picture, we have 3 types of testing.
- Mock testing
- Integration testing
- Contract testing
This is when you are testing your API against a mock consumer, the advantage is that it is very easy to implement and also cheap and it is done in very less time, the problem is that it won’t test the real world behaviour of the application and also the different challenges that the API might face when in usage cannot be identified when this testing approach is used
In this type of testing the API is tested against a real application, all the services and all are run and the API are tested as if they are being used in real world scenario. The advantage is that it gives a real world feel and usage of your API but the problem is that it is very costly and time consuming service but it definitely gives you the confidence that your API will work just fine in a real world scenario
This is the type where you get the best of both of the worlds i.e. integration and mock testing. It is fast and also gives the API developer’s the confidence that the API would function correctly in a real world scenario as well. In this we define a contract between a consumer and provider, the consumer tests against a mock provider and the provider tests against a mock consumer, here the mock request and response are defined in the contract which would be the same as if someone was using this in a real world application.
How many times have you found yourself in a situation where yesterday your API was working fine but today it is having errors/ not getting the data which you were previously getting and you have no idea how this has happened, maybe someone changed the entire API structure without informing you, to avoid this issue this is where contract testing comes in place, to give you an overview in contract testing a contract is established between the consumer of the service and the producer of the service and this is hosted on a broker(which stores the contract) and then every time any changes is done then this contract is checked to see if anyone has broken their part of the contract or not. Pact is on of the useful framework designed for this purpose, i will explaining pact in more detail:
From the above diagram you can see that here there are major players like consumer,contract,pact broker, provider. Let’s see them one by one:
- Consumer: As the name suggest this is the consumer of your API now this could be an http library, your application or any client that wants to interact with your API
- Contract: This is the agreement on which both the parties agree this is a place where the functions and different services provided but the API will be stored
- Pact broker: This is used for hosting your contract you can host it on AWS as well but pact provides it’s own hosting mechanism. This is the place from which the consumer and provide verify that the contract hasn’t been broken by anyone
- provider: This is your actual API which provides you the services and different functionalities
The flow goes something like this:
- The consumer starts the process of collaboration with provider to establish a contract
- The consumer write test for which functions it needs and then when this test are run this becomes the contract ,This is a JSON representation of all the various functionalities provided by the provider.
- Once this contracts have been established they have to be hosted somewhere, this is where the pact broker comes in and all these contracts are hosted on pact broker.
- Now the provider team starts to implement this API and it checks with the pact broker that all the requirements stated by the consumer are satisfied or not.
Once this is done i.e. the contract is published now the consumer can make request to the pact mock service provider and get back the data, similarly the mock provider can get request from pact mock consumer and then check if it meets all the requirements of the real consumer or not. Advantage here is no contracts are broken and the consumer can be tension that the provider will always give him the data that it needs.
As you saw that in consumer driven contract testing you are getting benefits of both your mock testing as well as integrating testing and also you get a confidence that your application won’t crash just because the provide changed the contract without telling the consumer. For more information you can see