Article Content
What Is Microservices Testing?
Microservices is a software design approach that breaks an application into small, decoupled services. Each microservice runs in its own process, and microservices are often distributed across different physical hosts. Services communicate with each other using a lightweight mechanism such as REST APIs.
Microservices testing introduces new challenges, due to the complexity of a microservices architecture, the difficulty of making microservices observable, and the new work culture that has evolved, where different teams develop different microservices, with limited communication between them.
Microservices Testing Challenges
Building distributed systems using microservices has many advantages, but testing these applications presents unique challenges. The naive approach is to test all service components of a microservice at the same time in the same environment, using traditional testing methods. However, this will not be a realistic test of a microservices application. In reality, most of the time the components will not be available in the same form or in the same environment.
Another concern is that a service component that implements an API (known as “provider”) is not aware of other service components that use its API (known as “consumers”). This means that after any provider microservice is updated, even if it is thoroughly tested, there is no guarantee that the changes do not break usage of the API by consumers.
You might consider setting up a test environment that will enable testing the process from end-to-end. However, this would be costly and complex, and automated tests will be too slow to be relevant for today’s high velocity development.
Another possibility is to perform extensive manual testing at the build stage to identify problems in service interaction. This is also difficult, because microservices applications can have a large number of components, and it is much easier to fully understand their behavior when observed in production, rather than in development phases.
Related content: Read our guide to microservices architecture
What Is The Testing Pyramid?
The Testing Pyramid is a useful model that can help organizations approach microservices testing. The model was originally developed by Mike Cohn in the era of service-oriented architecture (SOA), a predecessor of microservices architecture.
The basic idea is that to thoroughly test a system, the largest number of tests should be automated unit tests; there should be a smaller number of service-level tests testing interaction between components; and the smallest number of tests should be end-to-end UI or system tests.
The pyramid reflects the time and cost required to create tests and the value of running them. Unit tests check very specific features. They can be written quickly, have little redundancy, and can be executed relatively quickly. Running the same test cases through a UI or in an end-to-end system test is much more time consuming and does not add value, because the same UI elements would be exercised repeatedly in multiple unit tests.
While the general principle of the testing pyramid still holds, modern container-based, cloud-hosted infrastructure adds a new level of complexity. Microservices applications are decentralized systems—their behavior is unpredictable and a test environment cannot accurately simulate what is happening in production. This means that some post-production testing will be very valuable to validating the integrity and quality of the system as a whole.
In the context of microservices, the test automation pyramid can be translate to:
- Unit tests
- Integration tests between microservices
- End-to-end tests in a full microservices environment
Microservices Test Types
Microservices Unit Testing
Unit tests ensure that the code in each application component matches the necessary business logic, and is free of coding errors. According to the testing pyramid principle, unit tests should be the largest group of tests. They are very important for microservices applications because they can ensure that each individual microservice is working as intended.
In a microservices application, components do not have a standard size. They range from a few code blocks to thousands of lines of code. But whatever the size of each microservice, for unit testing to be effective, keep test units small and keep each test within the confines of the individual microservice, mocking out any external dependencies.
Microservices Integration Testing
You can use integration tests to determine how a unit and its dependencies behave when interacting with other units. In microservices applications, multiple microservices interact and work together to achieve a goal. Testers should monitor the requests flowing through the service to ensure that the communication channel is working as expected, and observe that each microservice returns the expected outputs to requests.
Microservices Component Testing
Ensuring that all parts work individually and have access to all external dependencies doesn’t mean the entire microservice will work as expected. To verify this, test the entire use case or process contained in a single microservice. External dependencies can be replaced with in-process mocks to speed up execution.
A component test starts by requesting a business function through a public interface, and confirms the expected results returned through the public interface.
Microservices Contract Testing
A critical element of a microservices architecture is that producers should meet their advertised API contract. This ensures that consumers can properly communicate with producers and get what they need.
Contract testing is typically done by the developers of a consumer service, and validates that a producer service provides expected responses to API calls made according to its published contract. If errors are discovered, they should be addressed by the developers of the producer service.
Contract testing is especially important if you have many distributed services running in production, and can also be valuable if your application interacts with external components, whether those components are producers or consumers.
Microservices End-to-End Testing
The top layer of hierarchical type testing is end-to-end testing. This type of test runs the entire microservices system with exactly the same setup as the production environment, or occurs in the actual production environment. A successful end-to-end test result means the user’s journey was successful—an end-user made a request and the microservices application as a whole provided the expected output within the service level agreement (SLA).
End-to-end testing is the most versatile type of testing, but that versatility comes at the cost of complexity. In addition, when issues are discovered in end-to-end testing of a microservices application, it can sometimes be difficult to diagnose and resolve the problem, because it might involve several moving parts within the application.
Microservices Testing Strategies
Full Stack in a Box
A major challenge when testing code on a local machine is that you can easily create problems on the machine. A full stack-in-a-box approach eliminates this risk and isolates the testing environment from the local machine. This strategy enables code replication from a cloud environment to a local machine, where the entire microservices testing process occurs in a local virtual environment.
Shared Test Instances
A shared test instance strategy is a hybrid approach of standard AWS testing and the full stack in-a-box approach. Testing occurs on a local, dedicated station but utilizes another shared microservice instance pointing to the main local environment during the test. In some cases, a microservice instance runs exclusively for local testing.
Stubbed Services
Stubs are dummy imitations of a microservice that behave like real services and appear as genuine services during discovery. A testing service might need the service to be aware of users performing certain tasks. Stubbed services behave the same but without the complexities that usually accompany user tasks. This strategy offers a lightweight alternative to running full services.
Black Box and White Box Testing
Black box testing is a blind testing approach, where the tester assesses the system from the outside without any knowledge of its internal workings. This external testing approach relies on observing inputs and outputs to deduct the system’s response mechanism. The opacity is intentional, so testers often choose to operate as outsiders even if they can see inside the system. For microservices, this approach is useful as it tests a microservice from the consumer’s perspective, and can provide feedback on microservice performance.
The white box testing approach leverages insider knowledge of the system’s source code, allowing testers to build test cases based on specific code functions. The tester understands the underlying code structure, so the emphasis is often on testing how a specific code change performs. An example of white box testing is unit testing, which is useful for testing internal aspects of a microservice.
5 Tips for Effective Microservices Testing
Here are several best practices for testing your microservices:
- Services—treat each service as a software module. Conduct unit tests on each service, treating each service as a black box. Ideally, you should test services similarly using a microservices testing framework.
- Links—identify essential links in your microservice architecture. Next, test these links separately. For example, to ensure a strong link between a user log-in service, you need the database storing user information and the front-end displaying it.
- Environments—trying to assemble the entire environment into a small testing setup is unnecessary and a waste of resources and time.
- Setups—diversifying your setup can help you catch more bugs, especially in complex virtual environments where every small difference between the underlying hardware and libraries can result in unintended functionality.
- Testing—use canary testing when introducing code changes to end-users. It involves testing new code changes on real users to ensure that code changes work as intended in real-world scenarios.
Microservices Deployment and Testing with Codefresh
Codefresh helps you answer important questions within your organization, whether you’re a developer or a product manager:
- What features are deployed right now in any of your environments?
- What features are waiting in Staging?
- What features were deployed on a certain day or during a certain period?
- Where is a specific feature or version in our environment chain?
With Codefresh, you can answer all of these questions by viewing one dashboard, our Applications Dashboard that can help you visualize an entire microservices application in one glance:
The dashboard lets you view the following information in one place:
- Services affected by each deployment
- The current state of Kubernetes components
- Deployment history and log of who deployed what and when and the pull request or Jira ticket associated with each deployment
The World’s Most Modern CI/CD Platform
A next generation CI/CD platform designed for cloud-native applications, offering dynamic builds, progressive delivery, and much more.
Check It Out