Understanding about Contract Testing

Yesterday Morning (9th May 2020), I had good discussion with Sundaresan Krishnaswami on "Contract Testing".

I thank Sundaresan for his time and sharing his knowledge.

It started with an example:

The Owner provides the house or Place of Residence to the Tenants.

"Rent Agreement" is provided for the house and It contains agreement to use the house.

The house comes with like kitchen, living room, bed room, fans, geysers etc..

It also contains who resides and what is the contractual period, obligation (money) etc..

Here, Owner is the Server and Tenant is Client.

                                        Client-Server Architecture.

Illustrating the same in the E-Commerce Context:

In Some Development Companies, There can be two teams developing the Payments and Orders APIs.

In B2B or B2C Ecommerce applications, we place an order using web browser through payment methods and Order is created.

Order is successful only when Payment is successful.

In general, Payments team has to inform Orders Team. 

To communicate the payments team will expose an API which the orders team will query and create the order.

Before/During the Development Process of APIs,  There will be an agreement between two teams (Payments Team and Orders Team)

1. Where to call the API (the endpoint)
2. What we will get as a response payload.
3. How to Query to Payment API

Documentation is more important for API Development. 

Based on the documentation Orders team will code their request to Payment API.

In turn, Payments Team will code their API to return the details to Orders Team.

Now, If payments team changes the name of one of the required fields and not informing the Orders Team. 
(say instead of the name payment_method_id, they change it to payment_method_type)

Now, the Order Process will be broken!  This can happen in production..!!!

Since Orders Team will be requesting payment_method_id, while it is changed to payment_method_type.

As per agreement, Payments team should inform Orders Team on the changes.

Here comes the Saviour...

If the orders team writes a contract using a tool like Pact (basically java/python code) and payments team integrate this contract in their test suite.

Whenever their builds are processed, the test suite runs, breaks if the contract is violated and alert is notified to the teams.

The contract here can be, as an Order team we will be requesting with API having the field payment_method_id.

If the payments team change this field name and try to run their build, it will break immediately since the contract is violated.

Now, Either Payments Team has to fix or Orders Team has to make changes to Fix this Process.

Contract Tests can fail even before actual testing starts (since the tests run along with your unit tests), issues are found much earlier in the testing phase.

Follow Sundaresan Krishnaswami: https://www.linkedin.com/in/sundarkris/