Foreword: this article is aimed at the front end development is using the unit test or has used or will use the students, because it involves the specific framework is the unit test framework Jest, so do not understand the students may see a little knowledge.

Of course, the core idea reflected in this article is not only for the optimization of unit test time, but from the actual situation of development, find the pain point in development, use engineering thinking ability, solve practical problems.

There are already articles on how to use unit testing, but I won’t go into too much detail: How to do front-end unit testing

Next I’ll think about how to optimize unit testing time in terms of the problems I’ve encountered in my development.

Pain points in development

After separating the branch from the base branch for development, merge into the target branch. Before merging, there is a CI process that includes Lint checking, unit test coverage checking, and so on.

As the project gets bigger and bigger, this CI takes more and more time, taking about 20-30 minutes at a time, even if only one file is being modified, while Lint and single tests need to run full time, which is a serious waste of time.

The single test is a file by file check, so if the last running file detects the problem, all the previous time will be wasted, or the last coverage is not passed, so you need to change the file again and run again.

The above process is a severe psychological torture for developers, and the development efficiency is seriously reduced.

The optimization thought before

It has been considered to force a single test check locally after the native code is developed but before the push code through the interface provided by Jest, but this would have the following problems:

  • During the development process, there was an urgent bug that needed to be fixed and branches needed to be switched. However, the code I had written was not able to use Git Stash in order to avoid the confusion of storage in git stack, so I had to push the code into the remote branch first, and it took a long time to force the check.
  • Requirements are not clear, component development is only to complete part of the function first, in order to save time, it is generally written after all components are completed. And after developing a page component to push the code to the remote side, and need to do a single test check, this situation because the single test is not written, unless ignored, or the single test must not pass.
  • Each push run single test and unified run single test, the time will be a lot of difference.

So it’s not possible to do that through the API provided by Jest.

Follow-up optimization ideas

Since the repository used by our team is Github and the action used by CI is also provided by Github, we wonder if there is a plug-in in the action that can get all the files changed in pr.

Also is there! Jitterbit /get-changed-files@v1 gets the changed file in the action!

Once you have the changed files, run nodejs script in the action and pass the path of these files to the script we wrote with the script parameters to do a single test check for these files.

Coverge tests between files are isolated and independent, so if you change only one file, you only need the unit test file of the file that Run changes. For modifying only a few configuration files, you can even skip running coverage.

Front-end unit test Coverage mainly detects three aspects: logic, snapshot, and coverage.

Logic and snapshots are not considered because of the isolation of single-test components. Coverage is divided into two aspects: coverage of individual files and overall coverage.

Jest does not specify coverage for an individual file, but has a percentage limit for the whole, and Jest’s method of calculating coverage (branch, functions, lines, statements) sums up the number of lines covered by all files.

Since it is a sum, only the changed file coverage rate may change with each change. Therefore, we can compare the coverage rate of the single file modified this time with that of the last file to get the change of the overall coverage rate. For a new file, you can add the total number of new code lines to the previous total number of code lines, and then add the number of new code lines to the previous number of covered code lines to obtain a new coverage rate and compare it with the previous one.

Specific steps

  1. Coverage on the latest branch of mastercoverage-final.jsonFiles are another way of expressing coverage (available by adding “JSON” to the coverageReporters configuration item in the jest.config.json file), which is utilizednycThis script can parse it into a TOTAL and individual file coverage JSON file, take the JSON and push it onto the Master branch. 
    {
  "total": {
    "lines": {
      "total": 46851."covered": 33931."skipped": 0."pct": 72.42
    },
    "statements": {
      "total": 56223."covered": 40519."skipped": 0."pct": 72.07
    },
    "functions": {
      "total": 10412."covered": 6544."skipped": 0."pct": 62.85
    },
    "branches": {
      "total": 26517."covered": 12924."skipped": 0."pct": 48.74}},"/src/common/image.ts": {
    "lines": {
      "total": 8."covered": 8."skipped": 0."pct": 100
    },
    "functions": {
      "total": 0."covered": 0."skipped": 0."pct": 100
    },
    "statements": {
      "total": 8."covered": 8."skipped": 0."pct": 100
    },
    "branches": {
      "total": 0."covered": 0."skipped": 0."pct": 100}}},Copy the code
  2. Modify the yML configuration file in the projectjitterbit/get-changed-files@v1The Github Action plugin gets all the pr files and adds them to the new script file with the script parameter.
  3. In the new script file, we filter the changed files (those that do not write single test files, those that ignore single test files, and various configuration files that do not need single test files). The filtered files NPM run covergae will get the coverage of these files and get their results through nyc parsing.
  4. If a file is modified, compare its coverage with the previous one. If a new file is added, compare its coverage with the previous one. You can see whether the change increases coverage, stays the same, or decreases coverage.

Through the above steps, the unit test time from 20min -> 3min, greatly improving the efficiency.

This idea is based on my team to develop the difficulty of optimization, the main idea is to cache, coverage of a subsequent development by making the action plugin to get the modified files, run these files individually coverage, compared with the previous buffer, and the other unchanged files needed for single measurement time reduced to zero.

Finally, I want to express: engineering is a kind of ability, but also a kind of thought!