This article is based on Song Jiachao’s speech at the 2021 Vivo Developer Conference. Public id reply ** [2021VDC] ** To obtain information related to the topics of the Internetworking technology sub-session.

The background,

1.1 Project Features

With the rapid development of Internet technology, more and more companies introduce the process of agile development into project iteration, so more and more projects present three characteristics:

1) Short iteration cycle: various inversion, pressing schedule, a small version a week, two weeks of large version, even some projects issued every day, unbearable.

2) Demand changes frequently: our product manager is either overturning himself or on his way to overturning himself. Therefore, we often joke with the product manager and say: Come on, please make a document to guarantee that you will not change the demand in the future. Product manager at this time said: good good, you change this requirement, I promise to give you written evidence, the next time never change. But it didn’t work, and the requirements still changed frequently. Of course, it’s not the product manager’s fault. Faced with a rapidly changing market environment, we sometimes need to use this trial-and-error approach to find the right solution quickly.

3) High system complexity: the front-end is no longer just a drawing page, as can be seen from the current front-end recruitment information. Distributed, microservices, middle tier, a variety of beautiful architecture, make the already complex business, become more complex.

As these features of the project became more apparent, so did our development and testing challenges.

1.2 the worry

So we have the following worries:

There are two main reasons for such worries:

Testers: They do not know where the change point of the development code is, where the impact point is, it is difficult to improve the test efficiency with accurate test scheme, so in order to be safe, they can only test all the relevant functions once

Developers: They do not have a comprehensive understanding of the execution of every line of code. It is difficult to analyze which code is useful and which code is not, which code has been tested and which code has not been verified through execution data

Therefore, we urgently need a platform that can easily see the changes and execution of the code, and this platform is the integrated code coverage platform.

1.3 plan

The so-called integrated code coverage platform refers to the platform that collects code coverage during the integration test and reports it to the system for display.

1.4 the difficulty

If there is a solution, why are there so few such products on the market today? When we looked at this, we found two very big technical difficulties.

The first difficulty is: data merge is difficult. As we all know, all front-end tests are carried out at each end, and the data generated by the tests are kept in each terminal, so it is difficult to collect and merge the data left in each terminal.

The second difficulty is: fast data failure. Front-end code version is very frequent, in the test, may be issued many times a day, although the version of the version is the same file, but the contents of the content may be completely different, so that the coverage of the previous collection will be completely invalid.

Through trial and error, we solved these two problems, and the Result was the Marco code Coverage platform.

Ii. Advantages and highlights of Marco Platform

2.1 Advantages and highlights

Marco platform is a complete code coverage platform with the following highlights:

Support one-click access: no business, framework, zero intrusion on existing code, one-click access;
Incremental reporting: provides users with a more accurate understanding of code coverage;
Support for multiple languages: Marco platform is not limited to the front end, can also serve the back end;
Support a variety of tools: easy to use, such as code comparison, gitBlame, etc.
Support multiple users: real-time merge and view of various reports;
Support market monitoring: view the trend of coverage rate in real time through the market to understand the trend of project quality;
Support message notification: regularly push project coverage;
Supports independent deployment: not only third-party access, but also one-click private deployment.

2.2 experience

2.2.1 details page

The first point on the chart below: what files have been changed in the current version, we will display all the changed files in the first area through a tree structure, so that users can see how many files have been changed in the current version at a glance
The second point in the figure below: where are the changes in the current file? We visually display the changes in each file in the second area by means of code comparison, so that users can see at a glance which lines of code have been changed in the file
The third point on the diagram below is whether the current change has been verified by the test. The second point is to mark which lines of a file have been changed. The third point is to mark whether the changed code has been verified.

With these three markers, we were able to integrate the changes into the testing process so that the results were clear.

2.2.2 trend diagram

Through the project trend chart, we can clearly see the trend of project coverage and understand the trend of project quality.

2.2.3 overview

At present, Marco platform has been running stably for nearly 3 months, serving 39 projects and generating 133 reports.

2.3 value

Through The Marco platform, we have closely linked the four points of test concern, namely, modification point, impact point, test point and test result, and transformed the previous evaluation lacking data into accurate, objective and quantifiable evaluation.

Iii. Technical scheme of Marco platform

The technical solution of Marco platform consists of four parts: firstly, the overall architecture of Marco platform will be introduced, and then the access layer, service layer and display layer will be explained in detail.

3.1 Overall architecture diagram

Marco platform is divided into three layers: access layer, service layer and display layer.

Access layer: Our goal is one-click access, multi-language adaptation, environment differentiation and intelligent reporting. Currently, the adaptation for the Web side is complete and is being adapted to other technology stacks such as applets, Node.js, Typescript. At the same time, we have also planned access methods for other languages, so that the Marco platform becomes a full-language code coverage platform.
Service layer: it mainly deals with various reports, such as report management, user management, project management and other functions.
Display layer: it is mainly an extension of the service layer. Through visualization, it provides more convenient report viewing and management functions.

3.2 Data flow diagram

Through the data flow diagram, we connect a report from the access layer to the service layer and then to the presentation layer to form a perfect closed loop.

3.3 access layer

The access layer is mainly about access and report.

For access: we provide various language piling scheme, piling specification, and access guidance.

For reporting: there are collection schemes, reporting data standards and reporting schemes for each language.

3.3.1 access

Dimension of pile insertion:

We usually divide staking into four dimensions: statement coverage, function coverage, branch coverage, and line coverage.

Insert the process

Mark in pile

This is Marco platform, PART of the JS peg code, mainly do three things;

Step 1: Obtain the relative path of the file

Why relative paths? Since Marco code coverage is a platform, we need to get the relative path so that the file path is associated with the project, not with the packaging machine.

Istanbul – Lib-instrument instead of completely rewriting the code, we used open source to make the Marco platform lighter and more versatile.
Step 3: Add custom parameters These parameters are important because they indicate important information about the current report.

So we simply completed the JS language peg adaptation, other languages can also refer to such ideas.

3.3.2 rainfall distribution on 10-12 report

Reporting is the process of collecting and sending.

For collection: mainly obtain two information, coverage information and project information, both are indispensable.

For sending: each end will be very different, we provide some suggestions. For example, Visibilitychange events can be monitored in the Web, and onShow and onHide events can be monitored in the small program. If it is reported in other servers such as Node, it can be reported through scheduled tasks.

3.4 the service layer

Marco’s service layer provides a lot of functions. Here we choose report management and user management, which are two typical functions to introduce.

3.4.1 Report Management

** First, a complete report needs to have three basic elements: coverage information, project information, and documentation information.

Coverage information includes statement coverage, branch coverage, function coverage and line coverage.
Project information includes: project configuration, branch information, file hash, and build time.
The file information includes the file address, file content, and Git information.

Marko can become a multi-user, multi-reporting coverage platform by collecting coverage and project information through the access layer and then associating file information with the Git platform.

3.4.2 Merge Process

In the last step, we collected coverage. Now let’s talk about how Marco platform merges reports. Let’s first consider two cases:

Case 1: The file has not changed;

It is the part on the left side of the picture below. When the file is not changed, there are two tests, and two reports are generated by Mei and Xiaohua respectively. In this case, how to merge them?

In the second case, the file has been changed;

The same document, the contents of the file changes, change the file before and after the line number can not one-to-one correspondence, such as file before change line 10, to change the file after, became the line 6, these two lines are the same, but because other lines cut as a result, the number of rows in the this line also has changed, this kind of circumstance how to merge again?

With these two questions in mind, let’s take a look at the reporting and merging process.

The tricky part is comparing report build times, which results in three results, one for each merge process.

3.4.3 Obtaining change Content

In the mainstream Git hosting platform, all provide the WAY of API interface to return git information. For example, the comparison information of two branches can be obtained through Gitlab’s Compare interface. By analyzing the returned information, we can know the changed content of the file.

3.4.4 User Management

In order to make the Marco platform as simple as possible, we use the general Oauth login method, through this way, not only solve the login problem, but also solve the problem of code permissions, is really multiple birds with one stone, of course, we design the login, fully consider the mainstream Git platform, Such as Gitlab, Github, Gitee, etc., which means that code hosted on these platforms can access the Marco code Coverage platform with one click.

3.5 show layer

This is the detail of the Marco platform report, which supports real-time brush reporting and code comparison. Through the comparison, we can see in detail the content of the file changes and the coverage of the corresponding content.

3.5.1 Code comparison

How does the Marco platform do code comparison?

We use an open source library called JSDiff, which allows us to compare the differences between two files. The result is an array of objects. This is an array of objects. The array contains four contents:

Count: the number of lines;
Value: specific code;
Added: Indicates whether the information is Added.
Removed: Indicates whether to be Removed.

By parsing the array, we can restore the comparison results to the page one by one, such as the lower right corner, which is the result of our restoration through the array.

Fourth, summarize the plan

So far, we have basically finished talking about the technical scheme of Marco code coverage platform. For Marco code coverage platform, we have two big plans in the future.

1) One is to enrich the access of languages at each end:

The front end includes applets, Node.js, and Typescript;
Other languages include Go, Java, etc.

2) Second, open source:

We will open source the whole Marco platform, embrace the open source community, and hope to work with you to build Marco platform.

Above are some of our explorations of code coverage, which can be used as an indicator of test quality and provides relatively reasonable and objective data. However, 100% code coverage does not mean 100% bug free. There is no clear correspondence between code coverage and the correctness of use cases, and it is only a supplement in the process of testing quality. Instead of blindly pursuing code coverage, we should find ways to design more and better use cases so that use cases and code coverage complement each other and improve project quality.

Author: Vivo official website Mall front-end team -Song Jiachao

mo4tech.com (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.