別慌這個報(bào)錯我見過太多次了。Execution failed for task :xxxx-api:test. No tests found for given includes:光是Gradle疑難雜癥列表里它就屬于出場率最高的那一檔?？雌饋硐馟radle在跟你說“沒找到測試”但絕大多數(shù)時(shí)候不是“真的沒有測試”而是“測試在Gradle不認(rèn)”。今天把這幾年踩坑攢下來的排查思路、修復(fù)寫法、團(tuán)隊(duì)規(guī)范一次性整理出來希望對剛接手Gradle工程或者CI里被這個紅牌卡住的同學(xué)有點(diǎn)用。1. 錯誤現(xiàn)場與問題本質(zhì)1.1 報(bào)錯信息可以拆成三個部分先別急著改代碼把報(bào)錯拆開看。Execution failed for task :xxxx-api:test說明是xxxx-api模塊的test任務(wù)執(zhí)行失敗冒號后面緊跟的No tests found for given includes: [模式]才是真正的原因。注意given includes這幾個字這里的“includes”是Gradle測試掃描的過濾條件一般來自三個地方命令行里的--tests參數(shù)比如本地調(diào)試時(shí)執(zhí)行過./gradlew test --tests com.example.FooTestbuild.gradle里test任務(wù)手動配置的include、filter { includeTestsMatching ... }IDEA或其它IDE點(diǎn)擊“運(yùn)行測試”時(shí)自動生成并透傳給Gradle的過濾參數(shù)如果你在命令行敲一個并不存在的--tests模式或者IDE里選中的目標(biāo)類有變化Gradle就會直接拋出這個錯誤。我以前在IDEA里運(yùn)行某個測試然后改了測試類文件名再跑去命令行跑整個test任務(wù)報(bào)錯也是它。所以第一步永遠(yuǎn)是先確認(rèn)這個include是誰給的給了什么1.2 “找不到測試”的真實(shí)鏈路Gradle定位測試類不是直接去src/test/java里數(shù).java文件而是走一條“編譯 → 掃描 → 匹配 → 執(zhí)行”的鏈路compileTestJava把測試源碼編譯為.class文件輸出到build/classes/java/testtest任務(wù)從編譯產(chǎn)物目錄收集所有.class按includes模式過濾Gradle默認(rèn)自帶三種模式**/*Test.class、**/*Tests.class、**/*TestCase.class將匹配到的類交給測試引擎JUnit 4或JUnit Platform引擎再從中識別具體的Test方法鏈路里任何一個環(huán)節(jié)出錯結(jié)果都可能是“No tests found”。換句話說這個報(bào)錯不是單點(diǎn)原因是一類問題的統(tǒng)稱。有人是編譯目錄里壓根沒有class文件有人是命名不對有人是JUnit引擎沒接上還有人純粹是命令行模式寫錯。下面這六類原因基本覆蓋了我遇到過的所有情況。2. 最容易踩中的六類原因2.1 測試類命名不在默認(rèn)include規(guī)則內(nèi)Gradle對“哪些類算測試類”有一套默認(rèn)匹配規(guī)則核心就是上面提過的三個模式以Test、Tests、TestCase結(jié)尾。也就是說UserServiceTest合法UserServiceTests合法UserServiceTestCase合法UserServiceCheck不行UserServiceIntegration不行TestUserService也不行很多團(tuán)隊(duì)從Maven遷移到Gradle時(shí)最容易踩這個坑。Maven Surefire的默認(rèn)包含規(guī)則是**/Test*.java、**/*Test.java、**/*TestCase.java它支持Test開頭的類名Gradle默認(rèn)規(guī)則里沒有**/Test*.class這一條所以TestUserService這種在Maven下能正常跑的測試類到了Gradle里就是透明人。另外類名匹配是大小寫敏感的userServiceTest和UserServiceTest看起來差不多Gradle只認(rèn)后者。這條原因雖然基礎(chǔ)但排查成本最低建議第一個看。2.2 測試代碼放錯了目錄命名沒問題也要看文件放沒放在Gradle約定的位置。Java插件的test任務(wù)只掃描src/test/java和src/test/resources這兩個目錄Kotlin插件則是src/test/kotlin。常見翻車場景測試類寫進(jìn)了src/main/java它會被編譯到main的產(chǎn)物目錄test任務(wù)根本不會掃描想?yún)^(qū)分單元測試和集成測試自己建了個src/integrationTest/java目錄但沒有配對應(yīng)的sourceSets和Test任務(wù)項(xiàng)目是Java和Kotlin混編測試類放在src/test/kotlin但Java插件對src/test/java和src/test/kotlin的SourceSet處理不一致導(dǎo)致部分文件沒進(jìn)compileTestJava遇到懷疑是目錄問題先執(zhí)行./gradlew :xxxx-api:sourceSets在輸出里找到test這個SourceSet看它的java.srcDirs到底指向哪。通常就能發(fā)現(xiàn)問題。2.3 測試框架引擎沒有接上這一條是我遇到次數(shù)最多的尤其在新建模塊的時(shí)候。Gradle本身不“認(rèn)識”Test注解它只是把候選class文件交給測試引擎去執(zhí)行。你的測試類如果用JUnit 5的org.junit.jupiter.api.Test寫但test任務(wù)沒有啟用JUnit PlatformGradle默認(rèn)按JUnit 4的路子去找運(yùn)行器找了一圈發(fā)現(xiàn)沒有結(jié)果就是零測試。典型配置長這樣dependencies { testImplementation org.junit.jupiter:junit-jupiter:5.10.2 testRuntimeOnly org.junit.platform:junit-platform-launcher } test { // 這里如果忘了寫 useJUnitPlatform() }依賴?yán)镉衘unit-jupiter但test塊里沒有useJUnitPlatform()等于引擎和任務(wù)完全對不上。還有一個和Java版本相關(guān)的坑Java 16以上如果只用junit-jupiter不帶junit-platform-launcher有些Gradle版本會報(bào)Launcher相關(guān)異常表現(xiàn)出來也可能是一次“找不到測試”。所以我的建議是JUnit 5工程里useJUnitPlatform()和junit-platform-launcher這兩個東西能寫多早就寫多早。2.4 命令行或腳本里的過濾條件寫歪了這就是given includes的直接來源。常見錯誤寫法./gradlew :xxxx-api:test --tests com.example.UserServiceTests模塊里明明只有UserServiceTest類名多了一個sGradle按UserServiceTests去匹配一個都撈不到直接報(bào)錯。還有人喜歡給--tests加.*后綴./gradlew :xxxx-api:test --tests com.example.UserServiceTest.*這種寫法通常也匹配不到Gradle的過濾模式是匹配類名路徑不是匹配方法。想跑某個包下的全部測試直接寫--tests com.example.*或--tests com.example.**就行。*匹配當(dāng)前包內(nèi)的類名**還能往下穿子包這個通配符語義比Ant風(fēng)格還好用。2.5 測試類根本沒有被編譯出來這條最隱蔽因?yàn)楸砻嫔稀皼]有測試類”實(shí)際上是因?yàn)閏ompileTestJava壓根沒有產(chǎn)出build/classes/java/test下的class文件。原因可能是src/test/java目錄不存在或?yàn)榭站幾g任務(wù)狀態(tài)是NO-SOURCE某個模塊的sourceSets配置被改過測試源碼目錄被移除了測試類自身依賴的類在測試編譯期報(bào)編譯錯誤但錯誤被某種方式掩蓋了比如增量編譯緩存異常遇到這種情況直接去產(chǎn)物目錄翻一遍find build/classes/java/test -name *Test.class如果目錄列表里沒有預(yù)期的class文件基本可以斷定是編譯階段的問題。再執(zhí)行./gradlew :xxxx-api:compileTestJava --info看看編譯任務(wù)是不是NO-SOURCE輸出里會寫得很清楚。2.6 測試類自身形態(tài)特殊還有一小部分情況問題出在測試類本身的寫法上。比如類被定義成abstract測試引擎無法實(shí)例化直接跳過類不是public并且用的是JUnit 4JUnit 4要求測試類必須是public的方法上掛著Test但導(dǎo)的是org.junit.jupiter.api.Test而項(xiàng)目實(shí)際用的是JUnit 4引擎不認(rèn)這個注解測試方法所在的類是非靜態(tài)內(nèi)部類默認(rèn)掃描不會把它當(dāng)候選測試類這類問題通常在IDE里跑是好的一上命令行就露餡。因?yàn)镮DE會直接運(yùn)行當(dāng)前文件而Gradle需要按掃描規(guī)則自己去找。3. 十分鐘定位法一套標(biāo)準(zhǔn)排查流程3.1 先看錯誤里的“given includes”是誰傳的拿到報(bào)錯先別動代碼讀完整輸出。No tests found for given includes: [com.example.FooTest]里的com.example.FooTest就是你該對的第一條線索。如果是命令行傳入的看下是不是自己手滑寫錯了如果是IDEA自動生成的看下是不是改了類名或包名之后沒刷新運(yùn)行配置如果是build.gradle里配的filter去把那一段改掉或注釋掉再試。這一步能濾掉一大半問題。我見過有人CI腳本里--tests com.example.*的包名在某個模塊里壓根不存在每次全量構(gòu)建必掛最后就是從報(bào)錯里的include模式溯源改掉的。3.2 再確認(rèn)編譯產(chǎn)物里有沒有測試類如果include模式?jīng)]問題下一步去確認(rèn)“目標(biāo)是否存在”。./gradlew :xxxx-api:compileTestJava find build/classes/java/test -name *.class | head -20有class說明源碼和編譯鏈路正常問題在后續(xù)的掃描匹配沒有class或數(shù)量不對問題在編譯/源碼目錄這一層。這個命令比任何花里胡哨的日志分析都直接十秒鐘定位到底該看哪一層。3.3 接著核對命名、注解與依賴確認(rèn)class存在后依次回答三個問題類名是否以Test、Tests、TestCase結(jié)尾類里的Test方法是否真實(shí)存在還是只有BeforeAll這種生命周期注解類路徑里有沒有對應(yīng)的測試引擎依賴依賴這一塊可以直接輸./gradlew :xxxx-api:dependencies --configuration testRuntimeClasspath看輸出里有沒有junit-jupiter-engine或者junit-vintage-engine。我遇到過一次測試類寫了Test但依賴?yán)镏挥衘unit-jupiter-api沒有junit-jupiter-engine編譯能過運(yùn)行一個測試都找不到。3.4 用三個命令縮小問題范圍寫一條完整命令去跑大概率還會報(bào)錯但換著縮范圍試# 用完整類名 ./gradlew :xxxx-api:test --tests com.example.UserServiceTest # 用包名 ./gradlew :xxxx-api:test --tests com.example.* # 全包掃描 ./gradlew :xxxx-api:test --tests com.example.**如果從完整類名失敗到包名成功說明類名或包路徑不對如果包名也失敗說明整個testSourceSet就沒掃描到這些class。這種由精確到模糊的測試方法基本能把問題圈在一個很小的范圍里。3.5 臨時(shí)打開testLogging看現(xiàn)場到了這一步還沒定位就打開testLogging看現(xiàn)場。在build.gradle的test塊里臨時(shí)配置test { useJUnitPlatform() testLogging { events started, passed, skipped, failed showExceptions true showCauses true showStackTraces true showStandardStreams true } }然后執(zhí)行./gradlew :xxxx-api:test --info。如果Gradle識別了測試類但執(zhí)行數(shù)為0日志里通常會有線索如果根本沒進(jìn)入執(zhí)行階段日志會明確告訴你掃描到的測試事件為零。這塊配置記得在排查完后移除或收斂不然CI日志會刷得很嚇人。4. 三個真實(shí)場景的修復(fù)過程4.1 場景一JUnit 5測試類被當(dāng)成“路人甲”某次新模塊提交的測試代碼UserServiceTest寫在src/test/java下類名合規(guī)注解也是org.junit.jupiter.api.Test依賴?yán)镆卜帕薺unit-jupiter但執(zhí)行test任務(wù)依然報(bào)No tests found for given includes: [com.example.UserServiceTest]。排查到build.gradle時(shí)發(fā)現(xiàn)test塊里只有幾行systemProperty配置沒有useJUnitPlatform()。因?yàn)檫@是從老工程拷貝出來的模板老工程模板是JUnit 4時(shí)代的寫法。修復(fù)很簡單test { useJUnitPlatform() }加上這一行之后再跑一次就正常了。這個模塊之所以報(bào)錯而不是“安靜地跑0個測試”正是因?yàn)槊钚袔Я?-tests指定了單個測試類過濾條件命中但引擎不認(rèn)。如果是裸跑test可能連失敗都沒有會被直接誤判成“正常通過”。4.2 場景二--tests通配符與包名不匹配有次CI報(bào)錯日志里的include模式是[com.example.api.**.*Test]一聽就是個“復(fù)合形”寫法。實(shí)際執(zhí)行./gradlew :xxxx-api:test --tests com.example.api.**.*TestGradle把**.*Test當(dāng)成了帶點(diǎn)的文件名匹配結(jié)果自然命中不了。改成./gradlew :xxxx-api:test --tests com.example.api.**就能把該模塊下所有測試都撈出來。這里給個經(jīng)驗(yàn)--tests后面寫包名或類名片段都可以但別把.class后綴、*Test這種文件通配符硬拼進(jìn)去。想指定某類測試--tests com.example.api.UserControllerTest就是最穩(wěn)的寫法。4.3 場景三自定義測試任務(wù)與sourceSet錯位一個工程里劃了unitTest和integrationTest兩個測試任務(wù)。integrationTest對應(yīng)目錄是src/integrationTest/java但新人建模塊時(shí)只建了目錄沒配sourceSets于是CI執(zhí)行./gradlew :xxxx-api:integrationTest --tests com.example.OrderIntegrationTest直接報(bào)No tests found。跑到build/classes/java/integrationTest一看目錄是空的壓根沒編譯。修復(fù)方案是在模塊的build.gradle補(bǔ)上對應(yīng)的源碼集和測試任務(wù)sourceSets { integrationTest { java.srcDir $projectDir/src/integrationTest/java resources.srcDir $projectDir/src/integrationTest/resources compileClasspath sourceSets.main.output runtimeClasspath sourceSets.main.output } } configurations { integrationTestImplementation.extendsFrom testImplementation integrationTestRuntimeOnly.extendsFrom testRuntimeOnly } tasks.register(integrationTest, Test) { description Runs integration tests. group verification testClassesDirs sourceSets.integrationTest.output.classesDirs classpath sourceSets.integrationTest.runtimeClasspath shouldRunAfter(tasks.named(test)) }配好之后再執(zhí)行compileIntegrationTestJava才會生成產(chǎn)物integrationTest任務(wù)也能掃到真正的測試類。5. 建團(tuán)隊(duì)規(guī)范時(shí)值得做的事5.1 把測試任務(wù)配置模板化“No tests found”最常見的原因就是配置不統(tǒng)一。每個新模塊都要靠人肉記住加useJUnitPlatform()那遲早會漏。我建議在根工程里統(tǒng)一兜底subprojects { tasks.withType(Test).configureEach { useJUnitPlatform() testLogging { events failed, skipped, standardError, standardOut exceptionFormat full showStandardStreams false } failOnNoTests false } }所有子模塊自動啟用JUnit Platform測試日志風(fēng)格也統(tǒng)一既減少漏配也方便排查。有人問failOnNoTests是干嘛的稍后單獨(dú)講。5.2 讓CI盡早暴露“無測試”問題Gradle的Test任務(wù)有個屬性叫failOnNoTests默認(rèn)false。默認(rèn)情況下一個模塊如果有src/test/java但一個測試類都沒有或者測試類全沒被掃描到test任務(wù)可能以NO-SOURCE或0測試的結(jié)果“成功”結(jié)束CI是綠的但沒人發(fā)現(xiàn)測試根本沒跑。這比報(bào)錯更危險(xiǎn)。把failOnNoTests設(shè)成true會讓“沒有測試”或“掃描不到測試”變成顯式失敗test { failOnNoTests true }這樣團(tuán)隊(duì)就會被迫處理“測試缺失”而不是放任不管。當(dāng)然也要權(quán)衡如果確實(shí)有些模塊沒有單測且不打算補(bǔ)就得給這些模塊單獨(dú)關(guān)掉這個開關(guān)否則CI一直紅著。我的習(xí)慣是框架模塊和工具包模塊關(guān)掉業(yè)務(wù)模塊強(qiáng)制打開。5.3 把診斷經(jīng)驗(yàn)沉淀成查表團(tuán)隊(duì)里新人遇到這個報(bào)錯第一反應(yīng)是滿世界搜。不如直接把排查順序?qū)戇M(jìn)文檔先看include來源、再看編譯產(chǎn)物、然后核命名和依賴、最后用--tests模糊匹配。配合第6節(jié)的速查表新人在五分鐘內(nèi)能自己解決大部分問題不用每次都艾特你。6. 常見問題速查表報(bào)錯表現(xiàn)通常原因排查/修復(fù)建議命令行指定--tests后報(bào)No tests類名/包名/通配符寫錯先放大范圍--tests com.example.*裸跑test任務(wù)報(bào)No testsbuild.gradle里的include/filter配置異常檢查test塊的include、filter { includeTestsMatching }新模塊測試全部找不到忘記useJUnitPlatform()test塊加useJUnitPlatform()依賴補(bǔ)junit-jupiter-engineIDEA能跑命令行跑不了IDE傳入的過濾參數(shù)與命令行不同檢查IDEA Run Configuration里的--tests參數(shù)build/classes/java/test下沒classcompileTestJava沒有產(chǎn)出檢查sourceSets確認(rèn)src/test/java存在且被識別測試類有Test但引擎不認(rèn)導(dǎo)包錯誤或引擎依賴缺失確認(rèn)注解是org.junit.jupiter.api.Test還是org.junit.Test多個自定義Test任務(wù)找不到類sourceSet和測試任務(wù)沒配對用testClassesDirs和classpath顯式指定Java 16環(huán)境異常缺少junit-platform-launcher增加testRuntimeOnly org.junit.platform:junit-platform-launcher這個表看著簡單但基本覆蓋了日常90%的場景。如果表格里沒有你的情況再回頭走一遍第3節(jié)的完整流程一定能在鏈路里找到斷點(diǎn)。最后一點(diǎn)個人體會這個報(bào)錯我前前后后處理過不下二十次九成以上不是代碼問題而是配置或命名問題。遇到它真的不用慌記住一條主線Gradle要先編譯出class再按include模式去匹配最后交給測試引擎執(zhí)行斷在哪一步就修哪一步。比起一遍遍刷--info日志我更推薦先去build/classes/java/test目錄下看一眼有沒有class文件十秒就能分成兩派——是沒編譯出來還是沒被掃描到。排查完再把配置模板化把useJUnitPlatform()這類基礎(chǔ)設(shè)置固化到根工程里以后新模塊基本不會再犯同樣的錯。如果非讓我只留一個技巧那就是裸跑./gradlew :xxxx-api:test看狀態(tài)再帶--tests com.example.**跑一次兩次結(jié)果對比一下問題定位立刻清楚一大半。