“This is the 8th day of my participation in the August More Text Challenge. For details, see: August More Text Challenge.”

preface

I will not repeat the concept of JaCoCo here. There are a lot of information On the Internet. Here I will mainly mention two modes of JaCoCo: on-the-fly and Offline

On – the – fly mode:

The JVM starts the Instrumentation agent by specifying a specific JAR file with the -javaAgent parameter. The agent determines whether to convert or modify the Class file before loading a Class through the Class Loader, and then inserts statistical code into the Class. Test coverage analysis can be done while the JVM is executing the test code.

Offline mode:

Before the test, the file is inserted, and then the class or JAR package inserted is generated. After the test of the class and JAR package inserted, the dynamic coverage information is generated into the file. Finally, the coverage information is uniformly processed and a report is generated.

However, JaCoCo’s offline piling mode is only available for Android projects, mainly because The Android system destroys this convenience of JaCoCo for the following reasons:

  1. Unlike the JVM running on the server, the Android virtual machine supports bytecode that must be specially processed to support Dalvik, ART, and other virtual machines, so the plugins must be completed before processing.
  2. Android virtual machines cannot be configured as parameters, so there is no chance to directly configure dump output to obtain coverage information at startup.

background

It’s based on two pain points:

1, a new functional test and regression test in manual test cases, even written in case again how detailed, and often there will be missing, here on the one hand, because now a lot of Internet company adopt outsourcing resources to do the test, and the quality of outsourcing work can’t effective evaluation, there may be a leak to perform, On the other hand, the design of test cases is not perfect enough to cover some critical path of the code branches, so a measure or tool to measure the code coverage after manual testing is completed is urgently needed;

2, r&d scope is difficult to accurately evaluate the influence of code changes, such as research and development to submit a MR, this MR how much influence the use cases, in the absence of precise testing capability is difficult to give, and do precision testing, is the most important part of library code cases relationship maintenance, how to generate the code with the relationship between the use cases, The ability to collect and analyze code coverage is needed;

In actual combat

In fact, the difficulty of doing Android code coverage based on Jacoco is mainly because the gradle plug-in of each project depends on the compatibility of jacoco version directly, especially in the development of multi-module projects for many years, this problem is particularly obvious, in addition, there are many articles on the Internet. Either the gradle plugin relies on an earlier version, or the Jacoco version, configuration file, and development environment of the project are not clear or written properly, making it difficult to follow the instructions.

So LET me explain my dependency first. I’m using version 4.0, which is relatively new and should be considered the mainstream project development environment:

Gradle plug-in version: the classpath 'com. Android. View the build: gradle: 4.0.1' gradle rely on version: distributionUrl=https://services.gradle.org/distributions/gradle-6.1.1-all.zipCopy the code

For a single module project, modify the source path and class file path in the jacoco.gradle configuration file.

The first step

Create a new jacoco.gradle file in app module. The code is as follows:

Which class file path, specifically related to gradle version, need to look at you the actual path, the diagram below:

Then rely on this jaco. gradle in your build.gradle file under your app module, as shown below:

Let’s put jaco. gradle in the root directory of the project as a general configuration, as follows:

If you need to count code coverage in submodules, you need to add the following dependencies to the build.gradle file of the submodule:

apply from: rootProject.file('jacoco.gradle')
Copy the code

The second step

Define a JacocoHelper class, which is used to generate ec files. It can be placed where you need it. For example, you can provide a button in the APP to trigger ec files, or you can trigger ec files from the command line.

Call the following methods where the EC file needs to be generated:

JacocoHelper.generateEcFile(true);
Copy the code

Generate test report

With the above two steps, we have completed the Jacoco configuration for the Android project, and we will show you how to use it to obtain code coverage for our manual or automated tests.

First, we can compile and install the Debug package integrated with Jacoco directly through Android Studio, and then execute the following command in the root directory of the project to complete initialization:

./gradlew jacocoInit
Copy the code

We can then start testing our use cases by executing an automated test script or manually. When the test is complete, execute the following command:

adb pull /storage/emulated/0/coverage.ec .
Copy the code

Place the resulting coverage.ec file in the location shown below, where the code-Coverage directory was generated by executing the initialization script.

Finally we execute the following command in the project root directory to generate the report:

./gradlew jacocoTestReport
Copy the code

At the location shown in the following figure, we can see the coverage report

Note:

Gradlew is the Wrapper and configuration for gradle. Gradlew is the Wrapper for gradle. Wrapper means Wrapper.

Since not everyone’s computer has installed Gradle, and the version installed may not be the one required to compile the project, gradlew is configured with the gradle version required by the project. Users only need to run GradLew to download the corresponding Gradle to the project directory according to the configuration. Only for the project itself.

The report analysis

The generated report is as follows:

Click on the package name to see the class coverage

Click on the class name to see which code is called and which code is not

The ground scene

Now that we can get code coverage based on the use cases executed, we can use this data to measure and accurately test, for example:

1. Business QA or outsourcing can use the coverage package to complete the testing of functional modules, so that the test effect can be measured according to the generated coverage data;

2, in addition when doing the test precision, we all need to maintain the relationship between the use cases and code library, so how to get the relationship, then we can through the manual or automated UI the cases in the process of putting each use case with corresponding code covered class file mapping relationship to complete the initial library;