Platform practice of Mock Testing – Challenger

background

Mock tests are becoming more and more widely used by companies as business systems increase and the speed of developers varies. However, there are also a series of disadvantages in the process of using mock tests:

1. Without a unified platform or basic framework, it is expensive to write mock scripts independently.

2. There is no platform for precipitation of past data, which is not convenient for later data modification and reuse when needed in the later period.

3. Start separately, maintain separately, not easy to debug, error rate is very high;

4. There is no uniform code maintenance standard and redundant files increase accordingly.

After referring to and investigating similar platforms in the market, the development practice is more suitable for the mock test platform we use based on our own problems and reflections.

Thinking about platform-based solutions

First, we need to sort out some of the functional scenarios implemented by the platform:

• Url Mapping (Unified Entry Management)

• Mock Basic configuration modules

• Parameter management module

• Rule configuration module

The overall architecture diagram is as follows:

The working flow chart is as follows:

Url Mapping-request receiving and parsing

Take the MOCK HTTP response as an example. Instead of using different scripts to receive different requests each time after the system request, the unified entry is used for receiving, as follows:

1 @RequestMapping(value = "/")
2 public String main(HttpServletRequest request) {
3    String contextPath = request.getContextPath();
4    String url = request.getRequestURI();
5    String path = url.substring(contextPath.length());Copy the code

Get the actual request address and cut out the request context.

There are many types of request, but also in the code to determine according to the request type, get the request type:

1 String method = request.getMethod(); 
 2 String contentType = request.getContentType();Copy the code

Mock Basic information configuration module

The configuration module is mainly used to configure the basic configuration of mock for different protocols. For example, it is divided into HTTP protocol mock and Dubbo interface mock. The unified maintenance entry allows you to add, delete, and modify interface information, which is convenient for testers to configure and maintain:

1) HTTP configuration is mainly composed of request custom URL, request type, and request body containing fields:

2) The basic configuration of DUBBO consists of the registry (registration address, timeout), protocol name, service name, application name and other related information. After the configuration, users can select the response interface and input the method name. The method name is the same as the method name of the interface provided by the system that needs to mock.

The registration configuration is shown below:

The effect after registration is shown as follows:

Parameter management module

This module provides the following functions to solve the current mock test situation where parameters cannot be passed down after a callback request:

• The information in the response body can be passed down so that the value of the information in the response can be obtained in a later request

• Parameter initialization decouples parameter values from request configuration information. Changing parameter values does not affect request configuration information and reduces the probability of configuration errors.

The parameter configuration interface is shown as follows:

Rule configuration module

This module is the business processing module of the whole platform. According to the request field, the corresponding rules are judged, as shown in the figure:

Rules are extracted from previous scripts and stored in a database for easy maintenance by testers, as is DUBBO rule configuration.

The platform result output is shown in figure

practice

At present, the platform has started to run, and the disadvantages of the test have been solved to a certain extent. The advantages are summarized as follows:

• Reduce the impact of different code levels of testers

• Parameters are separated from rule scripts, reducing configuration errors and enabling parameters to be passed down the flow

• Unified management of rules, independent storage, easy to change

Future prospects:

• Parse the interface document. You can standardize the interface document and import it directly into the system after writing it. The system can parse and generate mock scripts by itself

• Process customization to make the response data more consistent with business logic and real data.

Author’s brief introduction

Xiandao, Test R&D engineer of Tongbanjie, joined the team in March 2015, and is now mainly responsible for asset side project testing and automated test platform development.