background
With the growth of business, the demand for front-end is surging, how to ensure the quality of front-end code in a limited time. Through the unilateral guarantee of the students in the test, there are still inevitable front-line problems, regression is not in place or omission in the test, and there is no objective data to quantify the quality of the test. Through single measurement method, can be found that part of the problem in advance, reduce the cost of problem solving, but because of business form, requirements change frequently, functional iteration is fast, complement and maintenance of single test cost is higher, in the business side of most front-end engineering temporarily no single test method, so the development when the self-test, awareness is weak, There is no quantitative data, there is no unified index to check before the project is tested, and the test does not know the self-test status of the development. At the same time, the front a lack of integration test coverage statistics framework, like jacoco cannot be collected through integration test coverage, to the quality there is still no data of the testing phase quantization combining things said above, we put forward the front-end integration test coverage statistics tool needs, in order to promote development of self-test quality and project quality measurement, At the same time, it can help supplement the scenarios where regression is not in place or testing is missing, and improve the on-line quality.
Technology selection
First, the preconditions for coverage collection are code pegging, which comes from two open-source coverage statistical frameworks, Istanbul. Js and Istanbul – Middleware, which provide several pegging methods. Im is actually packaged based on Istanbul. Js, and its capabilities come from all the Istanbul lib-Instrument piling methods, which are roughly divided into two types: 1) pre-run piling and 2) in-run piling
#### insert before running nyc instrument Insert JS files manually to form a new JS file babel-plugin-istanbul The ability to embed peg code directly during the code compilation and packaging phase is useful for front-end projects that use Babel, as well as react and VUE based projects
#### runtime piling im.hookLoader is suitable for file mounting on the server side such as node applications. When the application starts, hook methods will be added to the require entry. Im. createClientHandler is suitable for client JS mounts. For example, the React and Vue JS files will block all JS file requests from the root path and return the pinned code. “Babel-plugin-istanbul” is similar to babel-plugin-istanbul, except that it returns a stake code only when the browser requests JS. It’s a dynamic process
| Insert pile way | function | advantage | disadvantage |
|---|---|---|---|
| nyc | Local manual piling source JS file, generated after piling file | Compiled JS can be manually inserted, no limit to the engineering framework | Files after manual piling need to be uploaded by themselves, which affects the original packaging and release process. Does not apply to service side piling |
| babel-plugin-istanbul | When Babel is compiled, the staking code is automatically generated | Low transformation cost, quick automatic piling | Restricted to projects using Babel |
| im.hookLoader | Add the hook method to the require entry to return the pinned code | Low transformation cost, quick automatic piling | This operation applies only to service end piling |
| im.createClientHandler | Intercepts the browser’s GET method for requesting static resource files and returns the staked JS | Automatic piling, no need to transform the original packaging process and script | Only applicable to client pile insertion; This method is based on Express and is limited to projects that use Express |
Finally we use plug pile method App (node) — istanbulMiddleware. HookLoader Client (the react & vue) – Babel – plugin – Istanbul
Module design
Code in the pile
The Client side uses the Babel-plugin-istanbul plugin, which is completed during Babel compilation
Rely on Node end istanbuljs ability – Istanbul – lib – hook, Istanbul – lib – instrument rewrite istanbulMiddleware. HookLoader method, Node before the start of mounting the file, The hook function will be added before the require method and code pegs will be added
Examples of pile insertion results
A coverage method will be added to the staked JS, which maintains and points to the ownership of coverage information and is used to obtain the coverage information of the file. Meanwhile, the method in this JS will leave marks on the path of execution and update the corresponding line or block information in the coverage information in real time after execution
### Data reporting
When the Node end application is published, the corresponding engineering and branch information is written, timers are created, and the _global.coverage variable is uploaded in real time, that is, the coverage information
The reporting of the Client side is special. Unlike the server side, the Client side can keep the coverage variable and timer method globally after the release. All the data generation and consumption of the Client side follow the life cycle of the page, so it is not controllable, so it needs an extra container for processing. We choose to report through chrome plug-in, through the global management of coverage information objects, and notification to achieve the reporting process. The detailed workflow of the plug-in is as follows
Coverage server
- Inherit the function of Istanbul Middleware
- Support for branch dimension receive and query coverage
- Coverage replacement when code changes, support for storing and viewing historical versions
Based mainly on Istanbul – middleware to do the secondary development, expanded the istanbulMiddleware. CreateHandler method
/:ns/:repo/ :ns/:repo/show The two coverage display interfaces add ns, repo, and branch inputs to distinguish different coverage rates. At the same time, an additional parameter, history, is added to indicate that the historical coverage rate is obtained
/client/:ns/:repo? Branch ={}&source={} body Carries coverage information and reports it based on the application and branch information. After receiving the reported information, the system obtains the coverage information of the branch and merges it with the reported information. Merging is performed based on the file name That is, code changes are made and the old coverage is discarded with the new coverage and stored in the historical version
The page display
The full coverage display is generated using istanbulMiddle’s native report
Incremental coverage display by comparing master differences through GitLab interface, showing their respective coverage by file, the same as full coverage, but refined, the whole page with Vue + Muse-UI completed
The working process
It is mainly divided into three parts, corresponding to the access, reporting and display of client code staking through Babel plug-in. The staking plug-in provided for node can be used to complete the code staking on the server side in one step and the chrome plug-in provided with periodic reporting function. The coverage rate reporting task on the client Is completed. The coverage rate server receives and stores information, and returns the information to the front-end end. The front-end end displays data information
Business practices
Access to the test environment publishing platform to realize the real-time coverage collection and display function of multiple versions in application and branch dimensions, so as to seamlessly connect with the project test environment. After the release of each application in the project, the coverage report will be automatically enabled, and the project test process will be recorded and viewed in real time. Before the project is tested, quantitative indicators for development can be given. After the project is tested, final coverage data can be provided to help test students check and improve the functions that are not covered. At present, it has been connected to e-commerce education and industry business lines. Because this tool is limited to qa environment, it can only collect project data tested in QA environment. In the functional test stage, from the perspective of usage data, the coverage rate of incremental line code reaches more than 80% (the current increment only reaches the file dimension, not the line dimension), and the uncovered lines mainly include four types: exception capture, defensive coding, and redundant codes that are not newly added and do not need to be concerned with this time, which belong to the allowable range.