In recent years, although micro-service is very popular, there are still many people do not like micro-service, and even boycott it. The main reason is the high cost and difficulty. As far as difficulties are concerned, there are a number of unsolvable problems, including the following three related to test data and test environment: Test Interview Guide

Problem 1: The test environment is used by multiple teams

In large-scale microservice systems, certain core services are often invoked by multiple teams and may have multiple dependent services. When a test environment for a service is used by multiple teams (services), there are two main difficulties. 1. The same test data may be modified by different teams. Some teams have solved this problem by creating multiple test environments, but this is costly. For many Internet companies with strong technology, they can reduce some costs by means of Docker and other technologies, but for many traditional enterprises, it is difficult to implement the multi-environment with high cost. 2. The same test data may be occupied by other teams. The so-called occupation means that once a test data is accidentally used by someone, he may use it according to his own scenario.

2 problem 2: It takes a lot of time to prepare test data

When testing systems that are not very complex in their business, it may not be difficult to prepare test data. However, in some traditional industries, such as banking, insurance, communication and other complex systems, preparing test data is a very difficult thing. I once tested an insurance system, and it took hours to prepare a set of data in the test environment, because the business was so complex, the database design was so complex, and it was a legacy system, and almost no one knew how to manipulate the database directly to prepare the data. Therefore, the preparation of the data must be created by the system. While the system itself is based on MainFrame, and the UI is all under Console, the operation is very tedious and complex, resulting in a long time to create a set of test data. The core systems of many banks and insurance companies remain the same. Therefore, in such legacy systems in traditional industries, the preparation of test data is a very big problem. Secondly, in many systems, once the test data is used, the state will change, so that it can not be reused. So retesting requires recreating test data, which is a common and serious problem.

3 Fault 3: The test environment is unstable and the version does not match due to service deployment or network problems

This is a common situation. This may not be a problem for stable, unchanged systems, but it is quite common for systems that are under development, have a lot of changes, or are inherently unstable. Some service deployment and network issues, it is easy to understand, are dependent services being deployed. The second is that the dependent service is being debugged, and during debugging, some of the state of the service itself may be constantly changing. Or there are bugs in the dependent service, resulting in problems with the service. In the end, the user may only need the 1.0 version of the dependent service, but the 2.0 version of the service is already deployed in the test environment, so the user cannot use the service.

Solution: Service Virtualization can address these issues using the Service Virtualization technology. Here is a simple schematic of service virtualization:

While service virtualization may seem simple, its implementation already has rich features, such as Hoverfly, to address the above set of problems.

4Hoverfly

Hoverfly is an open source free (Apache 2) service virtualization tool where virtual data is reusable Json format Simulation. It’s light and efficient, based on Go. Both Python and Java extensions are supported, and REST apis are provided to control them. It also provisionally provides analog network delays, random errors, and rate limits. For the time being, only HTTP and HTTPS are supported. But the most important thing is that it supports six working models: Capture model, Simulate model, Spy model, Synthesize model, Modify model, and Diff model. Through these six models, various functions of service virtualization can be realized. First, the Capture model allows you to Capture data about how services interact with each other during manual tests and when the system is in use, and then analyze and modify it to Capture more types of data. Use the Spy, Synthesize, Modify, and Simulate models to perform different types of service virtualization. Different teams can quickly customize their own private virtual cubes according to the basic type of data. In addition, different versions of virtual cubes can be customized according to different versions of services, thus isolating data between different versions of services and avoiding test data conflicts between different teams.

Here’s a look at each of the six models.

4.1 * * * * the Capture model

The Capture model is a standard recording capability. Hoverfly is a standard Proxy service at this point. By placing it between the service under test and the external service, you can record all the interactive data into a specific Json file, called Simulation. Simulation can then be changed to suit different requirements and used in other models.

4.2 * * * * Simulate model

Simulate is the standard Stub model. You can load simulations recorded from the Capture model or manually written simulations directly into Hoverfly, Then any Request that satisfies the matching rules in Simulation will return the virtual Response in Simulation, otherwise it will not return any correct Response.

4.3 * * * * Spy model

The Spy model is one of the most specialized models and one I use most often in formal projects. Its most special function is to allow some requests to get a virtual Response, while other parts of the request to get a real Response.

Therefore, by changing the test data itself, you can determine whether you are using a real dependency system or a virtual dependency activity. In this case, the traditional Stub tool might need to be implemented manually, at least by default. However, Hoverfly is supported by default, so simply add the rule to the virtual file in Hoverfly to make it work.

Secondly, there are times when I need both virtual and real data in the same test environment, and the Spy model is the best solution. Because only in this way can the lowest cost, to achieve both the real data can be measured, and virtual data can be measured.

Why is this model needed? Large-scale regression tests cannot rely on external services because of the unstable test environment, so they rely on virtual data. But still test some external real services, why? Because you’re worried about external service upgrades? It is possible that after the upgrade, the Request and Response schemas of the service have changed, resulting in a Bug. In reality, some of the so-called important scenarios are still run by the real external service, so that even if the Schema of its external service changes, the test can detect the change in the first place.

So, this is the most classical and practical model.

* * * * 4.4 Synthesize model

The most important requirement of the Synthesize model is to return dynamic Response data according to different situations.

In this case, Hoverfly provides an intermediate plug-in function. You can develop an intermediate plug-in based on Python or Java. When a Request is received, it can encrypt and decrypt the Request and make a specific judgment. And then return a specific Response.

Request can be judged and processed, and some specific combinations can be made for Response, which is not a fixed value, or a fixed one or two values.

4.5 * * * * the Modify model

After the actual Request is received, the Modify model can transform the Request into specific content and send it to the external dependency. The external dependency returns to the Response and then returns to the specific mode, so as to realize the virtual state of the specific state.

For example, you need to simulate a Request with something added, or you need to make some confusion, generate some specific use case, or change some data in the real Response.

4.6 * * * * Diff model

The Diff model is a variant of the contract test scheme. First, when the system’s API is tested, it saves the data returned by the dependent service. When the same test case is executed the next time, it compares the data returned from the previous test case with the data returned from the current dependent service.

If the next Schema is different from the one stored the first time, Hoverfly will alert and display the two different schemas. This is equivalent to doing a passive contract check between the system under test and the dependent system, although it is not part of a full contract test scheme, but at least a unilateral contract check.

Why Hoverfly?

First of all, service virtual centralization is based on Proxy model, so it only needs to add a machine to build a service. Second, it is non-intrusive. It does not need to change the code or configuration of the system under test, but only the JVM’s own property or the operating system’s Proxy configuration. Then it’s very flexible, it supports a variety of models, and it’s very easy to use. Finally, it is open source software, so you can modify it for your own use if you have specific customization requirements.

5 concludes

With the development of traditional Stub and Mock service technology, as well as the various problems and requirements of service testing in the development of microservice system, service virtualization is born. Service virtualization is an enhancement and systematization of stubs and mocks, making them easier to use and customize to meet new requirements for service testing and to address emerging issues. Test interview guide