关于 gitlab 上 Java 项目测试覆盖率

gitlab 中是支持将项目的测试覆盖率解析的, 简单来说就是通过设置正则表达式从 CI 中的日志抓出覆盖率的相关信息(参见官方文档), 我虽然觉得这个方式挺 LOW 的, 但也没有什么其他办法. 记录一下 Java 项目的接入过程.

0x01 Java 测试覆盖率统计

Java 是有一些第三方工具进行测试覆盖率统计的, 原理也很简单:

1. 使用 Java Instrumentation 技术将字节码改写, 添加一些标记代码, 以备在代码真正被执行的时候标记哪些逻辑/哪些分支被执行
2. 执行 Unit Test 代码
3. 收集标记代码产生的数据并统计覆盖率, 生成测试覆盖率报告

可选方案也有一些, 罗列几个我熟悉的:

1. Clover, Atlassian 出品, 收费
2. Cobertura, 开源, 最后更新是2015年(怀疑已经没人维护)
3. Jacoco, 开源, 并且项目依旧活跃

选型原则也很简单, 一看是否有自己所用的 build 工具集成, 毕竟自己再去写一个 build 工具 plugin 也费力气; 二看结果是否满足需求.

由于 Cobertura 不怎么更新了, 我这个 Cobertura 老用户也切换到了 Jacoco.

0x02 接入 gitlab CI

接入也很容易, 由于使用 maven 作为 build 工具, 因此只需要在 pom.xml 中添加如下内容, 就可以在 mvn clean test 执行后自动获得覆盖率统计报告, 在 target/site/jacoco/index.html 中

<build>
    <plugins>
      <plugin>
         <groupId>org.jacoco</groupId>
         <artifactId>jacoco-maven-plugin</artifactId>
         <version>0.7.9</version>
         <executions>
            <execution>
               <id>pre-unit-test</id>
               <goals>
                  <goal>prepare-agent</goal>
               </goals>
            </execution>
            <execution>
               <id>post-unit-test</id>
               <phase>test</phase>
               <goals>
                  <goal>report</goal>
               </goals>
            </execution>
         </executions>
      </plugin>
    </plugins>
</build>

同样, 接入 gitlab CI 也是简单, 由于覆盖率统计结果在 html 报告中, 因此在项目的 .gitlab-ci.yml 中执行 mvn clean test && cat target/site/jacoco/index.html 即可将覆盖率信息打印到 LOG 中, 最终 gitlab 会通过 coverage 的正则解析到覆盖率. 正则也很简单:

Total.*?([0-9]{1,3})%

将上述正则填写到项目 Pipeline settings 中

0x02 采坑开始

用上诉方法接入了多个项目都没有问题, 遇到一个 Presto plugin 的项目就诡异的报错了, 现象就是:

1. 没有 jacoco-maven-plugin 的情况下执行 mvn clean test 测试成功执行
2. 添加了 jacoco-maven-plugin 就会报如下错误:

testValue(data.Test)  Time elapsed: 0.006 sec  <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class com.facebook.presto.spi.block.BlockBuilderStatus
    at data.Test.testValue(Test.java:40)
    sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
    at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

不过作为 Java 老司机, 看到 java.lang.NoClassDefFoundError: Could not initialize class com.facebook.presto.spi.block.BlockBuilderStatus 就知道是 com.facebook.presto.spi.block.BlockBuilderStatus 这个类的什么静态方法执行失败, 导致 com.facebook.presto.spi.block.BlockBuilderStatus 初始化不成功.

翻了一下日志果然发现如下错误:

Caused by: java.lang.IllegalArgumentException: Cannot determine size of boolean[] because it contains an array
    at com.facebook.presto.spi.block.BlockBuilderStatus.deepInstanceSize(BlockBuilderStatus.java:77)
    at com.facebook.presto.spi.block.BlockBuilderStatus.deepInstanceSize(BlockBuilderStatus.java:92)
    at com.facebook.presto.spi.block.BlockBuilderStatus.deepInstanceSize(BlockBuilderStatus.java:92)
    at com.facebook.presto.spi.block.BlockBuilderStatus.<clinit>(BlockBuilderStatus.java:26)
    ... 33 more

通过阅读源码发现 com.facebook.presto.spi.block.BlockBuilderStatus 根本就没有 boolean[] 类型的属性, 猜测是 jacoco 在改写字节码的时候添加了一些属性, 用于标记代码是否被执行. 通过 jacoco-maven-plugin 中添加 exclude 排除所有 preseto 相关代码, 问题解决.

<configuration>
    <excludes>
        <exclude>com/facebook/**/*</exclude>
    </excludes>
</configuration>

总结

gitlab 接入一下测试覆盖率还是很有必要的, gitlab 还支持在项目的 README.md 中添加覆盖率和 build status 的 badge, 从侧面敦促工程师尽量提升测试覆盖率. 反正我看到低于 80% 覆盖率的项目都是嗤之以鼻的.

覆盖率 badge

还有一个收获就是先了解原理, 在动手干活儿很重要, 遇到问题从原理角度定位问题比盲目的瞎尝试效率高得多.

-- EOF --