Shulou(Shulou.com)06/03 Report--

This article focuses on "how to master the testing core of microservices". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how to master the testing core of microservices".

The difference between traditional testing and micro-service testing

Traditional test model abstraction

The server side in the above figure includes n functions. The traditional service is that all functions are deployed on one machine, and the capacity is expanded by increasing the number of servers. Refer to the following figure (each color represents a function, and four sets of the same services are deployed)

Microservice test model abstraction

Unlike traditional testing, microservices often do not have UI pages, and we need to invoke each service interface by building a request (through coding or tool simulation). Microservices are deployed on a business-by-business basis. Each service in the above figure represents a function, and different businesses are deployed on different servers. Frequently used businesses can also be deployed with more resources (five units are deployed in orange in the figure below, while only one unit is deployed in Mei Hong), so that resources can be used more reasonably.

The main test content of micro-service

Unit testing: verify that the code behaves as expected from the perspective of the minimum testable unit in the service in order to test defects at the method and class level.

Integration testing: verify that the communication or interaction between the current service and the external module is as expected in order to test for interface defects.

Component testing: limit the scope of testing to a part of the system under test (usually a single service) and use a test stand-in (mock) to isolate it from other components in order to test for defects in the code under test.

Contract testing: verify the interaction between the current service and the external service to show that it conforms to the contract expected by the consumer service, essentially verifying the interface specification

UI test: traditional dot-by-dot page test.

Among them, integration testing, component testing and contract testing are the focus of our testing, and the above three tests can be understood as interface testing (we will not discuss in detail what interface testing is here). That is, each service provides an external interface, and then we invoke the service through this interface, and finally verify that the return value is as expected! We can use coding or tools to build the interface and make a request to the interface, and then follow the interface documentation to verify that the response is as expected.

Considerations for microservice testing

Micro-services can be divided into undependent services and dependent services.

Undependent services: you can provide complete service functions to meet the needs of callers without the need for other services. We can test the interface provided by the service directly.

Dependent services: they can not meet the needs of the caller, need other services to provide one or more functions, together to provide complete service functions to the caller. At this time, we need to isolate other micro-services that a single micro-service depends on, so as to avoid blocking the testing process and invalid testing due to the impact of dependent services (such as service unavailability, service defects, etc.). Mock technology is usually used to isolate the tested service from the dependent service, so that the service link is stable and the environment is controllable, which is beneficial to the testing process. The concept of Mock originates from unit testing. In unit testing, we only focus on the units being tested, not on other dependencies. Mock allows us to have a simulation environment so that we do not have to worry about the failure of the verification process due to the environment when checking the internal flow process within the unit. Because of the diversity of the external environment, the unit test should design some exception scenarios so that the code can catch the exception. For example, in figure a below, if we are going to test A, we need to build the entire dependency tree, that is, an instance of BCDE, which is extremely expensive. One alternative is to use mock, as shown in figure b, we only need to specify that Mock B and Mock C give the corresponding response after receiving the request from A (there is no need to perform complex logical operations in Mock B and Mock C). At the code implementation level, we can implement mock operations through mockito (for java).

Figure a

Figure b

What is the service of mock in microservice testing? For example, we turn the payment function into a microservice, which is responsible for handling the logic of the payment, and in the final payment, we need to call Alipay to complete the payment. So how to deal with this scene? In a simple way, we spend a penny to actually buy the service. What if we want to verify the purchase of services for 10000 yuan? Or what should our program do when Alipay makes a mistake? Here we can regard Alipay as a mock service, and the core implementation ideas are as follows:

Parse the application request and return a pre-defined response value, as shown below:

1. The payment request is verified correctly and the payment is returned successfully.

two。 Payment request verification failed. Return payment failed.

3. Turn off Alipay mock service, you can simulate Alipay exception

We can use wiremock to build our own mock server. The simple principle is shown below:

We need to set a predefined request in the configuration file and return a predefined response if the applied request matches the predefined request. Then start wiremock to process the request. Wiremock is a web server! For more information, please refer to https://github.com/tomakehurst/wiremock

Summary of microservice testing

1. If you only do UI functional testing, then micro-service testing is no different from traditional testing, because you only can't feel the architectural change.

two。 The interface testing provided for each microservice is essentially equivalent to interface testing. It is necessary to test the interface function, performance and security according to the interface documentation of the microservice.

3. If necessary, it is necessary to use mock to simulate the services that micro-services depend on to improve the testability of the services under test.

4. Focus on load balancing and test whether requests are distributed to multipoint applications. Reference article: the key to microservice performance testing-- IP spoofing technology

5. Monitor the resources (including cpu, memory, disk, network) consumed by each service through tools SpringCloud Sleuth, Turbine, Prometheus

6. Centralize management logs through ELK (ElasticStack). Reference article: the key to microservice testing-querying logs through ELK

7. Understand the core concepts of microservices. Reference article: identify the essence of microservice testing in this article

At this point, I believe you have a deeper understanding of "how to master the testing core of micro-services". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.