A Microservice architecture consists of a collection of small, autonomous services. Each service is self-contained and should implement a single business capability. Although this type of architecture helps teams with agility, scalability, and easy fault isolation, etc., there are several challenges when it comes to development and testing: testing a small service that relies on other dependent services requires a different approach than testing a traditional monolithic or layered application; adapting the automation pyramid or traditional tools and practices that have helped us in the past is currently unfeasible.

Test strategies for microservices consist of four key parts:

1. The Unit Test
2. The Component Tests — The behavior of every endpoint in a microservice under a test using mocks and stubs for the external microservice it needs to interact with is tested.
3. System Integration Test - here we spin up all the microservices to verify the combined behavior of all the microservices. These tests are helpful to test the shared behavior between microservices and to validate user journeys using endpoints without the need for a client.
4. Contract Tests — there are two peers — a consumer (client) and a provider (service). We define an API contract on the ‘consumer’ side - the contract must be enforced on the service provider. The contract tests are useful as they eliminate the need to set up the entire platform in a test environment. They help in verifying message formats (requests and responses). In the picture above (Fig 1.1), client interaction with the microservices can be confirmed by contract testing.

In this blog, I’m going to discuss some ideas on how to create an API System Integration Test framework using Python. To exemplify this, I will be using Spotify endpoints.

#software-development #testing #api #devops #spotify