Integration Testing

As an example, let’s take a system made of three components:

Browser — a browser app for adding cookies

Storage — a service that stores cookie information

Quality Service — a service that checks cookie quality

1. Browser sends a request to add a new cookie to Storage
2. Storage sends a request to Quality Service, to check if the cookie meets the quality requirements

3. Quality Service returns a response to the storage Approved, or Rejected depending on the result
4. if the quality service returned Approved, the storage saves the cookie and responds to the browser OK
   if the quality service returned Rejected, the storage does not save the cookie and responds to the browser Bad Request

It turned out that the component Quality Service is not ready yet, so to test the interaction between Browser and Storage we use a stub.

Stubs can be written by developers or testers.

Stub simulates the work of Quality Service and returns two possible responses:

• round cookies Approved
• not round cookies Rejected

Integration testing of component 1 with component 2 (using a stub instead of component 3) comes down to checking two main scenarios:

1. the cookie passes the quality check and should be added to Storage,
   Browser should receive the response with status OK
2. the cookie fails the quality check and should not be added to Storage,
   Browser should receive the response with status Bad Request

In the positive scenario, when two components integrate successfully, we expect the server to return an HTTP response with code 200 OK to the client’s request. But there are also other response codes shown in the table.

The system under test consists of two components: client and server.

The frontend developer created the client part — “Form for sending an HTTP request”, and the backend developer wrote the logic on the server. They agreed on the rules for successful data exchange and aligned the API.

Take the role of the client and check if the components work together successfully.