“This is the 25th day of my participation in the Gwen Challenge in November. See details: The Last Gwen Challenge in 2021”

The first two days have realized the Jest test framework environment construction, basic test case writing and how to interpret the test coverage, do not contact the suggestions to see, attached article link:

  1. Jest | Test framework practice – Basics and environment setup
  2. Jest | Test Framework Practice – Test case writing and coverage interpretation

When we execute jest –coverage, it generates the following test report:

How does it work?

The principle of speculation

Coverage generated by generating index see jest framework for statement, function, branches, number of rows to generate these four dimensions, if the js compilation principle, according to acuity big physical speculation to should be a need for js to do the ast tree parsing, because of the type of this a few indicators, on the number of the corresponding ast node type has a corresponding embodiment. When parsing into an AST tree, there should be some mechanism to hack into the tree so that it can count which types of nodes in the AST tree have been executed.

The principle of validation

The usual first step to understanding how a library works is to open the package.json file of the class library and see what it depends on. Through the investigation of this file, we excluded the following three libraries:

  1. istanbul-lib-coverage: provides a read-only view of coverage information and an API that merges and summarizes coverage information
  2. istanbul-lib-reportThe Istanbul library’s core program for generating reports
  3. istanbul-reports: Provides a common capability API for reporting output in general

These three libraries are used around Istanbul, so the library basically provides core coverage capability with a high probability. Let’s verify that.

Istanbul library

Istanbul, inserts line counters for ES5 and ES2015+JavaScript code so you can track how unit tests are running against the code base.

Let’s install a look:

npm install -g istanbul
Copy the code

After installation, run Istanbul Help to see what naming it supports. All the core commands are as follows:

  1. check-coverage: Checks the overall/per-file coverage based on the COVERAGE threshold of the JSON file. If the threshold is not met, exit 1; otherwise, exit 0.
  2. cover: Transparently adds coverage information to node commands. Save coverage. Json and the report at the end of the execution.
  3. instrument: Inserts a file or directory tree and writes the code for the insert instruction to the desired output location.
  4. report: Writes coverage reports to JSON objects generated during the last run.
Instrument command

An instruction inserts code, usually to find information, which is called a function peg and adds code to a function. Verify the following:

// test.js const toSum = (a, b) => {if (a > 10) {return a + b + 10; } return a; }; toSum();Copy the code

Execute this command to add code to the test.js file and print it to the test-inst.js file:

istanbul instrument ./test.js -o ./test-inst.js
Copy the code

The converted code, formatted, looks like this:

You can see the following information:

  1. It creates a global object to store statistics
// The format is as follows: var coverages = {'/root/test.js':{path: '/root/test.js', // Number of statements s: {}, // Number of branches b: FnMap: {}, // statementMap: BranchMap: {}}} branchMap: {}}Copy the code
  1. It inserts statistical code into the corresponding positions of the code executing the function, and the corresponding code blocks are executed+ 1
  2. Naming and its complexity prevent global naming conflicts.

That’s the whole Istanbul process, and that’s the fundamental principle behind the generation of coverage.

conclusion

This article provides an overview of how jEST test coverage is generated, and its basic implementation mechanism is understood. And I’ll talk about the Istanbul library and how it works and how it works.