gitlab 中是支持將項(xiàng)目的測試覆蓋率解析的, 簡單來說就是通過設(shè)置正則表達(dá)式從 CI 中的日志抓出覆蓋率的相關(guān)信息(參見官方文檔), 我雖然覺得這個(gè)方式挺 LOW 的, 但也沒有什么其他辦法. 記錄一下 Java 項(xiàng)目的接入過程.
0x01 Java 測試覆蓋率統(tǒng)計(jì)
Java 是有一些第三方工具進(jìn)行測試覆蓋率統(tǒng)計(jì)的, 原理也很簡單:
- 使用 Java Instrumentation 技術(shù)將字節(jié)碼改寫, 添加一些
標(biāo)記代碼, 以備在代碼真正被執(zhí)行的時(shí)候標(biāo)記哪些邏輯/哪些分支被執(zhí)行 - 執(zhí)行 Unit Test 代碼
- 收集
標(biāo)記代碼產(chǎn)生的數(shù)據(jù)并統(tǒng)計(jì)覆蓋率, 生成測試覆蓋率報(bào)告
可選方案也有一些, 羅列幾個(gè)我熟悉的:
- Clover, Atlassian 出品, 收費(fèi)
- Cobertura, 開源, 最后更新是2015年(懷疑已經(jīng)沒人維護(hù))
- Jacoco, 開源, 并且項(xiàng)目依舊活躍
選型原則也很簡單, 一看是否有自己所用的 build 工具集成, 畢竟自己再去寫一個(gè) build 工具 plugin 也費(fèi)力氣; 二看結(jié)果是否滿足需求.
由于 Cobertura 不怎么更新了, 我這個(gè) Cobertura 老用戶也切換到了 Jacoco.
0x02 接入 gitlab CI
接入也很容易, 由于使用 maven 作為 build 工具, 因此只需要在 pom.xml 中添加如下內(nèi)容, 就可以在 mvn clean test 執(zhí)行后自動(dòng)獲得覆蓋率統(tǒng)計(jì)報(bào)告, 在 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 也是簡單, 由于覆蓋率統(tǒng)計(jì)結(jié)果在 html 報(bào)告中, 因此在項(xiàng)目的 .gitlab-ci.yml 中執(zhí)行 mvn clean test && cat target/site/jacoco/index.html 即可將覆蓋率信息打印到 LOG 中, 最終 gitlab 會(huì)通過 coverage 的正則解析到覆蓋率. 正則也很簡單:
Total.*?([0-9]{1,3})%
0x02 采坑開始
用上訴方法接入了多個(gè)項(xiàng)目都沒有問題, 遇到一個(gè) Presto plugin 的項(xiàng)目就詭異的報(bào)錯(cuò)了, 現(xiàn)象就是:
- 沒有 jacoco-maven-plugin 的情況下執(zhí)行
mvn clean test測試成功執(zhí)行 - 添加了 jacoco-maven-plugin 就會(huì)報(bào)如下錯(cuò)誤:
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 老司機(jī), 看到 java.lang.NoClassDefFoundError: Could not initialize class com.facebook.presto.spi.block.BlockBuilderStatus 就知道是 com.facebook.presto.spi.block.BlockBuilderStatus 這個(gè)類的什么靜態(tài)方法執(zhí)行失敗, 導(dǎo)致 com.facebook.presto.spi.block.BlockBuilderStatus 初始化不成功.
翻了一下日志果然發(fā)現(xiàn)如下錯(cuò)誤:
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
通過閱讀源碼發(fā)現(xiàn) com.facebook.presto.spi.block.BlockBuilderStatus 根本就沒有 boolean[] 類型的屬性, 猜測是 jacoco 在改寫字節(jié)碼的時(shí)候添加了一些屬性, 用于標(biāo)記代碼是否被執(zhí)行. 通過 jacoco-maven-plugin 中添加 exclude 排除所有 preseto 相關(guān)代碼, 問題解決.
<configuration>
<excludes>
<exclude>com/facebook/**/*</exclude>
</excludes>
</configuration>
總結(jié)
gitlab 接入一下測試覆蓋率還是很有必要的, gitlab 還支持在項(xiàng)目的 README.md 中添加覆蓋率和 build status 的 badge, 從側(cè)面敦促工程師盡量提升測試覆蓋率. 反正我看到低于 80% 覆蓋率的項(xiàng)目都是嗤之以鼻的.
還有一個(gè)收獲就是先了解原理, 在動(dòng)手干活兒很重要, 遇到問題從原理角度定位問題比盲目的瞎嘗試效率高得多.
-- EOF --
