| Feature Name | Description |
|---|---|
| Testing types | |
| Unit Testing |
This type of testing helps you validate the performance of each component (or unit) of your software. A unit can be an object, a module, a procedure, function, or method. You can define the size of the unit but be advised that smaller units are the easiest to test. Furthermore, if you are struggling to define a unit test, consider it an indication your module should be broken down into smaller pieces. Ideally, developers should perform unit testing during the development phase, to ensure all code components are working properly and as designed. However, during rushed development or when teams are working in siloed phases, the quality assurance (QA) team may be required to perform unit testing—after the developers completed their work on the project. |
| Contract Testing Specific to microservices |
The contract specifies all the possible inputs and outputs with their data structures and side effects. Contract tests ensure that microservices adhere to their contract. They do not thoroughly test a service’s behavior; they only ensure that the inputs and outputs have the expected characteristics and that the service performs within acceptable time and performance limits. Consumer-side contract tests Producer-side contract tests |
| Integration tests | Integration tests on microservices work slightly differently than in other architectures. The goal is to identify interface defects by making microservices interact. we want to make sure that the microservices can communicate with one another and their own databases. We’re looking for things like missing HTTP headers and mismatched request/response pairings. |
| Component tests |
A component is a microservice or set of microservices that accomplishes a role within the larger system. Component testing is a type of acceptance testing in which we examine the component’s behavior in isolation by substituting services with simulated resources or mocking. Component tests are more thorough than integration tests because they travel happy and unhappy paths — for instance, how the component responds to simulated network outages or malformed requests. |
| In-process component testing |
In this subclass of component testing, the test runner exists in the same thread or process as the microservice. We start the microservice in an “offline test mode”, where all its dependencies are mocked, allowing us to run the test without the network. In-process testing only works when the component is a single microservice. |
| Out-of-process component testing | Out-of-process tests are appropriate for components of any size, including those made up of many microservices. In this type of testing, the component is deployed — unaltered — in a test environment where all external dependencies are mocked or stubbed out. |
| End-to-end testing | End-to-end (E2E) testing ensures that the system meets users needs and achieves their business objectives. The E2E suite should cover all the microservices in the application using the same interfaces that users would–often with a combination of UI and API tests. The application should run in an environment as close as possible to production. Ideally, the test environment would include all the third-party services that the application usually needs, but sometimes, these can be mocked to cut costs or prevent abuse. |