戰(zhàn)：MockMvc到Testcontainers)
要說SpringBoot項(xiàng)目里最容易被敷衍對待的部分測試絕對排得上號。很多人寫測試就是給Service方法加個(gè)Test跑一下發(fā)現(xiàn)綠燈然后就沒有然后了。可等到接口被改、數(shù)據(jù)庫切換、并發(fā)上來之后最先崩潰的往往就是那堆形同虛設(shè)的測試。我早年也吃過這個(gè)虧后來才慢慢把一個(gè)SpringBoot項(xiàng)目的測試體系從“會(huì)跑”折騰到“能救命”。這篇文章就把我在實(shí)戰(zhàn)里沉淀下來的那套打法完整梳理一遍覆蓋從依賴選型、分層策略到MockMvc、Mockito、Testcontainers的落地細(xì)節(jié)以及那些文檔里不會(huì)寫的坑。1. 測試在SpringBoot項(xiàng)目里的定位與分層思路1.1 為什么SpringBoot測試常?！靶瓮撛O(shè)”很多項(xiàng)目的測試代碼看起來不少覆蓋率報(bào)表也好看但一遇到重構(gòu)就稀里嘩啦碎一地。我見過最常見的病根是把測試寫成了“實(shí)現(xiàn)細(xì)節(jié)的復(fù)讀機(jī)”。比如Service層剛調(diào)了userMapper測試?yán)锞蚼ock一堆when(userMapper.selectById()).thenReturn(...)然后斷言返回值。一旦把Mapper換成別的數(shù)據(jù)源測試全部紅掉可業(yè)務(wù)邏輯明明沒變。這種測試的問題在于它驗(yàn)證的是“代碼是怎么寫的”而不是“行為是否正確”。所以我在項(xiàng)目里反復(fù)強(qiáng)調(diào)一個(gè)原則測試要對著契約寫不要對著實(shí)現(xiàn)寫。接口的輸入輸出、異常規(guī)則、狀態(tài)流轉(zhuǎn)才是契約至于底層用的什么框架、什么ORM都不該是單測關(guān)心的重點(diǎn)。這個(gè)認(rèn)知不糾正后面所有工具和技術(shù)都是在錯(cuò)誤的路上加速。1.2 測試金字塔在SpringBoot里的落地方式測試金字塔這個(gè)概念不新鮮但在SpringBoot里落地時(shí)很多人會(huì)跑偏。理論上應(yīng)該是底層單元測試最多、中間集成測試適中、頂層端到端測試最少?？蓪?shí)際上因?yàn)镾pringBoot的SpringBootTest太方便了很多團(tuán)隊(duì)直接把所有測試都寫成全量上下文啟動(dòng)一個(gè)項(xiàng)目跑下來測試要十幾分鐘于是大家越來越不想寫測試。我在實(shí)踐中會(huì)把測試分成三類來管控單元測試針對Service、工具類、領(lǐng)域?qū)ο蟛粏?dòng)Spring容器用Mockito隔離依賴。切片測試只加載某一層需要的Bean比如WebMvcTest只加載Controller和MVC相關(guān)配置DataJpaTest只加載Repository和數(shù)據(jù)源相關(guān)配置。集成測試啟動(dòng)完整上下文必要時(shí)用Testcontainers拉起真實(shí)MySQL、Redis等中間件驗(yàn)證跨模塊交互。這三類的比例我會(huì)控制在7:2:1左右。單元測試和切片測試跑得快合并請求時(shí)全量執(zhí)行沒壓力集成測試數(shù)量少、價(jià)值高放在發(fā)版流水線里跑。1.3 一套可持續(xù)的測試策略長什么樣可持續(xù)的關(guān)鍵不是覆蓋率數(shù)字而是反饋速度和穩(wěn)定性的平衡。我見過太多測試綠了但其實(shí)是假綠原因無非是斷言寫得寬松、數(shù)據(jù)沒清理干凈、隨機(jī)端口沖突等等。所以我會(huì)給項(xiàng)目定幾個(gè)硬規(guī)矩所有測試必須能重復(fù)執(zhí)行跑十次結(jié)果一致不允許依賴執(zhí)行順序。測試之間不允許共享可變狀態(tài)數(shù)據(jù)庫、Redis、文件系統(tǒng)必須在每個(gè)用例結(jié)束后恢復(fù)。單元測試和切片測試總耗時(shí)控制在兩分鐘以內(nèi)超過就要拆分。任何測試失敗先解決測試本身不允許用Disabled掩蓋問題。這些規(guī)矩剛定的時(shí)候會(huì)有人覺得麻煩但堅(jiān)持下來之后測試是真的敢在發(fā)版前給人信心的。2. 測試環(huán)境搭建與依賴選型2.1 spring-boot-starter-test里都有什么SpringBoot的測試依賴非常省心起步就在pom.xml里加一個(gè)spring-boot-starter-testdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency這個(gè)starter做了很多底層整合不是簡單地把JUnit扔給你。它默認(rèn)帶了一套組合好的測試工具箱JUnit 5Jupiter現(xiàn)在的基礎(chǔ)測試框架Test、ParameterizedTest、RepeatedTest都靠它。Spring Test Context提供SpringBootTest、Transactional傳播、TestContextManager等能力。MockitoMock、InjectMocks、when/verify的核心來源。AssertJ流式斷言庫assertThat(...).isEqualTo(...)比JUnit原生的assertEquals可讀性好太多。Hamcrest老牌匹配器雖然AssertJ更常用但一些遺留代碼里還會(huì)見到。JSONassert用于對比JSON結(jié)構(gòu)接口測試斷言返回體時(shí)很有用。還有個(gè)容易被忽略的是spring-boot-test-autoconfigure所有WebMvcTest、DataJpaTest這類切片注解都來自它。它保證切片測試自動(dòng)裝配配置時(shí)不會(huì)誤加載其他層的Bean。需要單獨(dú)補(bǔ)依賴的話一般是加mockito-inline用于mock靜態(tài)方法和Testcontainers相關(guān)的模塊這個(gè)后面細(xì)說。2.2 測試目錄與命名規(guī)范目錄結(jié)構(gòu)直接用Maven/Gradle的標(biāo)準(zhǔn)test目錄就行我習(xí)慣把測試類按照被測試類的包結(jié)構(gòu)鏡像并且保持一套統(tǒng)一的命名規(guī)范團(tuán)隊(duì)成員看著不迷路Service層單元測試UserServiceTestController層切片測試UserControllerWebMvcTestRepository層切片測試UserRepositoryDataJpaTest集成測試UserServiceIntegrationTest命名這件事看起來細(xì)枝末節(jié)但作用非常大。跑測試的時(shí)候看到類名就知道它在測哪一層、需不需要容器環(huán)境排錯(cuò)效率直接翻倍。還有個(gè)小技巧把單元測試、切片測試、集成測試通過Maven Surefire的groups或命名后綴區(qū)分開方便在本地只跑某類測試。2.3 測試配置文件的隔離這是非常關(guān)鍵又容易被忽略的一環(huán)。application.yml里往往配置了真實(shí)環(huán)境或開發(fā)環(huán)境的數(shù)據(jù)源、緩存、消息隊(duì)列地址測試如果直接復(fù)用輕則連錯(cuò)庫重則把測試數(shù)據(jù)寫到生產(chǎn)環(huán)境旁邊的關(guān)系庫里去。我一般會(huì)建一個(gè)src/test/resources/application.yml用配置覆蓋的方式只保留測試需要的內(nèi)容spring: datasource: url: jdbc:tc:mysql:8.0.36:///test_db driver-class-name: org.testcontainers.jdbc.ContainerDatabaseDriver jpa: hibernate: ddl-auto: create-drop redis: host: localhost port: 16379注意這里的數(shù)據(jù)庫地址不是真實(shí)的MySQL地址而是Testcontainers的JDBC驅(qū)動(dòng)地址后面集成測試部分再展開。關(guān)鍵是要理解SpringBoot配置文件加載時(shí)有優(yōu)先級src/test/resources下的文件優(yōu)先級高于主目錄下的application.yml這樣測試項(xiàng)目可以放心覆蓋配置而不用改動(dòng)主代碼的配置。3. 容器測試與切片測試怎么選SpringBootTest用前先想清楚3.1 全量上下文啟動(dòng)的利與弊SpringBootTest是SpringBoot測試?yán)锏摹爸亓考夁x手”它的作用是啟動(dòng)完整的Spring容器把幾乎所有的Bean都裝配起來。好處是貼近真實(shí)運(yùn)行環(huán)境壞處也是顯而易見的啟動(dòng)一次要加載數(shù)據(jù)源、Redis連接、消息隊(duì)列、各種初始化邏輯一個(gè)中型項(xiàng)目跑單個(gè)測試可能就要十幾秒到幾十秒測試一多就完全跑不動(dòng)了。我見過一個(gè)項(xiàng)目光啟動(dòng)容器就要40秒90個(gè)測試類跑完接近一個(gè)小時(shí)。這個(gè)成本導(dǎo)致開發(fā)人員完全不想在本地跑測試最后測試形同虛設(shè)。所以我在新項(xiàng)目里對SpringBootTest的使用非常謹(jǐn)慎只有下面幾種場景才用它跨模塊的端到端業(yè)務(wù)鏈路驗(yàn)證比如從Controller入口一直打到數(shù)據(jù)庫。配置類的加載驗(yàn)證比如自定義的ConfigurationProperties是否綁定正確。需要完整容器環(huán)境的第三方對接聯(lián)調(diào)。其他場景能用切片就用切片。這個(gè)觀念轉(zhuǎn)變之后測試的反饋速度能提升一個(gè)數(shù)量級。3.2 切片測試更快但不是萬能SpringBoot為每個(gè)常見層次都提供了專門用于測試的注解。我這里先列幾個(gè)最常用的切片注解加載范圍典型用途W(wǎng)ebMvcTestController、Filter、ControllerAdvice、MVC配置不加載Service和Repository測試接口參數(shù)校驗(yàn)、路由映射、返回值結(jié)構(gòu)DataJpaTestRepository、Entity、數(shù)據(jù)源配置默認(rèn)使用內(nèi)嵌數(shù)據(jù)庫并開啟事務(wù)回滾測試倉儲(chǔ)層的CRUD、查詢規(guī)則、分頁排序JsonTestJackson/Gson的ObjectMapper相關(guān)配置測試JSON序列化和反序列化規(guī)則RestClientTestRestTemplateBuilder相關(guān)的RestClient配置測試遠(yuǎn)程HTTP客戶端調(diào)用邏輯MybatisTestMyBatis的Mapper和配置需引入第三方starter測試MyBatis的SQL語句映射WebMvcTest是我每天都會(huì)用到的。它只加載Web層Service用MockBean新版本里推薦MockitoBean或MockBean具體看Spring版本打樁。這樣啟動(dòng)速度非?？煲粋€(gè)Controller相關(guān)的測試類通常在幾百毫秒內(nèi)就能跑起來。不過切片測試也不是萬能藥。WebMvcTest不會(huì)加載你自定義的攔截器之外的全局配置如果攔截器依賴了Service里的數(shù)據(jù)就需要額外把相關(guān)Bean補(bǔ)進(jìn)測試上下文DataJpaTest默認(rèn)用內(nèi)嵌H2替換真實(shí)數(shù)據(jù)庫如果項(xiàng)目里用了MySQL特有的JSON字段或全文索引H2大概率模擬不出來這時(shí)候就得考慮Testcontainers。3.3 不同場景下的選型對照我在實(shí)際項(xiàng)目中形成了一張很實(shí)用的對照表每個(gè)新開發(fā)者進(jìn)來我都會(huì)先發(fā)這張表防止他們憑感覺選測試方式測試目標(biāo)推薦方式啟動(dòng)速度真實(shí)度是否要mockController參數(shù)校驗(yàn)、路由WebMvcTest快中mock ServiceService業(yè)務(wù)規(guī)則純JUnit Mockito極快低mock Repository/外部ClientRepository查詢邏輯DataJpaTest較快中取決于數(shù)據(jù)庫類型不需要跨層主流程SpringBootTestTransactional慢高看情況外部中間件真實(shí)聯(lián)測SpringBootTest Testcontainers慢極高一般不需要這個(gè)表格背后真正的判斷標(biāo)準(zhǔn)是三個(gè)問題測的是哪一層這層最關(guān)心的風(fēng)險(xiǎn)是什么需要多高的環(huán)境保真度想清楚這三個(gè)問題選型就不會(huì)錯(cuò)。4. Controller層測試實(shí)戰(zhàn)MockMvc的關(guān)鍵細(xì)節(jié)4.1 MockMvc 基本套路Controller層的測試最常用MockMvc配合WebMvcTest使用不需要真正啟動(dòng)Web容器。直接發(fā)起HTTP請求然后對返回的響應(yīng)做斷言。下面這段代碼是典型的用法WebMvcTest(UserController.class) class UserControllerWebMvcTest { Autowired private MockMvc mockMvc; MockBean private UserService userService; Test void shouldReturnUserWhenIdExists() throws Exception { UserVO mockUser new UserVO(1L, 張三, zhangsanexample.com); given(userService.findById(1L)).willReturn(mockUser); mockMvc.perform(get(/api/users/1) .accept(MediaType.APPLICATION_JSON)) .andExpect(status().isOk()) .andExpect(jsonPath($.name).value(張三)) .andExpect(jsonPath($.email).value(zhangsanexample.com)); } }given是Mockito BDD風(fēng)格的寫法等價(jià)于when(...).thenReturn(...)只是可讀性更好。很多人寫Controller測試時(shí)習(xí)慣直接調(diào)Controller的方法這樣其實(shí)繞過了路由解析、參數(shù)綁定、序列化這些真正的風(fēng)險(xiǎn)點(diǎn)測試價(jià)值大打折扣。用MockMvc走一趟完整請求鏈路才檔得住真實(shí)的調(diào)用問題。4.2 斷言比調(diào)用更重要測試的核心不是把請求發(fā)出去而是做足夠嚴(yán)謹(jǐn)?shù)臄嘌?。我見過不少同事寫完andExpect(status().isOk())就收工了根本沒驗(yàn)證返回內(nèi)容。這種測試跟沒寫差不多接口里面隨便改點(diǎn)東西都會(huì)照常綠。我給團(tuán)隊(duì)定的標(biāo)準(zhǔn)是至少覆蓋狀態(tài)碼status().isOk()、isCreated()、isBadRequest()等。業(yè)務(wù)字段用jsonPath逐一斷言核心字段不允許只斷一個(gè)$.code。關(guān)鍵時(shí)序涉及異步或重定向時(shí)檢查響應(yīng)頭里的Location或狀態(tài)流轉(zhuǎn)。異常路徑參數(shù)缺失、資源不存在、權(quán)限不足每一種都得有對應(yīng)的用例。JSONPath斷言是接口測試?yán)锏睦?。假設(shè)返回體是{data: {items: [{id: 2}, {id: 5}]}}可以這樣寫.andExpect(jsonPath($.data.items.length()).value(2)) .andExpect(jsonPath($.data.items[1].id).value(5))注意length()這個(gè)函數(shù)式寫法很多人在第一次接觸JSONPath時(shí)會(huì)漏掉導(dǎo)致斷言怎么寫都不對。4.3 常見翻車點(diǎn)我在接口測試?yán)锊冗^不少坑挑幾個(gè)典型分享MockBean的返回值類型不一致如果UserService.findById返回的是OptionalUserVO但代碼里處理的是null判斷mock時(shí)容易返回Optional.empty()而忘掉對應(yīng)邏輯分支然后測試通過的代碼拿真實(shí)數(shù)據(jù)就出問題。建議mock時(shí)先確認(rèn)生產(chǎn)代碼的判空路徑。日期時(shí)間格式LocalDateTime默認(rèn)序列化格式是數(shù)組比如[2025, 5, 1, 10, 30, 0]。如果接口要對前端返回yyyy-MM-dd HH:mm:ssController測試?yán)锉仨汄?yàn)證這個(gè)格式否則到聯(lián)調(diào)時(shí)才暴露就晚了。分頁參數(shù)的默認(rèn)值Spring Data的分頁接口如果沒傳page和size會(huì)走默認(rèn)值。測試?yán)锶绻粶y默認(rèn)值后面前端傳錯(cuò)參數(shù)也沒人發(fā)現(xiàn)。靜態(tài)資源處理WebMvcTest默認(rèn)不會(huì)加載靜態(tài)資源映射如果Controller里有重定向到靜態(tài)頁面的接口測試?yán)锟梢酝ㄟ^手動(dòng)添加資源處理器或者改用SpringBootTest。還有一點(diǎn)很多人不知道MockMvc的perform其實(shí)會(huì)在內(nèi)部走完整的DispatcherServlet所以Valid注解觸發(fā)的參數(shù)校驗(yàn)在WebMvcTest里是真實(shí)生效的。換句話說Controller層的參數(shù)校驗(yàn)測試完全可以在切片環(huán)境里做不需要跑到集成測試?yán)镌傺a(bǔ)。5. Service層單元測試Mockito的正確姿勢5.1 基礎(chǔ)三件套Service層是業(yè)務(wù)邏輯的聚集地測試價(jià)值最大但也是最容易被寫壞的。我常用的基礎(chǔ)模式是MockInjectMocksExtendWith(MockitoExtension.class) class UserServiceTest { Mock private UserRepository userRepository; Mock private PasswordEncoder passwordEncoder; InjectMocks private UserService userService; Test void shouldCreateUserWithEncodedPassword() { String rawPassword abc12345; given(passwordEncoder.encode(rawPassword)).willReturn(encoded-value); User created userService.createUser(zhangsan, rawPassword); assertThat(created.getPassword()).isEqualTo(encoded-value); verify(userRepository).save(any(User.class)); } }ExtendWith(MockitoExtension.class)是JUnit 5與Mockito集成的入口沒有它Mock和InjectMocks不會(huì)生效。InjectMocks會(huì)優(yōu)先按構(gòu)造器注入其次是setter和字段注入這要求被測類的依賴盡量通過構(gòu)造器聲明否則容易注入不進(jìn)去。5.2 別mock一切很多人寫Service測試時(shí)有個(gè)壞毛病把Service內(nèi)部依賴的私有方法也通過mock去繞開。實(shí)際上Mock只能作用于類的公開協(xié)作對象私有邏輯該測還是得測。更糟糕的是有些人會(huì)把UserRepository.save(...)的返回值mock成一個(gè)帶ID的復(fù)雜對象結(jié)果Service里后續(xù)依賴的字段沒設(shè)置測試和真實(shí)行為對不上。我踩過一次最深的坑是某個(gè)下單流程里OrderRepository.save()返回的訂單對象里有個(gè)凍結(jié)金額字段我mock的時(shí)候忘了set值導(dǎo)致后續(xù)計(jì)算一直為0測試卻綠了。上線后真實(shí)數(shù)據(jù)一跑就出狀況。那之后我定了個(gè)規(guī)則能少mock就少mock能走真實(shí)對象就走真實(shí)對象。Repository里的方法如果有清晰的返回規(guī)則我寧愿寫個(gè)真實(shí)的實(shí)體對象傳進(jìn)去也不想mock出個(gè)殘缺對象。另外verify經(jīng)常被用錯(cuò)。verify(userRepository).save(...)驗(yàn)證的是這個(gè)調(diào)用發(fā)生過一次但如果你想要的是“最終調(diào)用了兩次”這種次數(shù)斷言需要配合times(2)。不要濫用verifyNoMoreInteractions()它會(huì)把測試綁死在實(shí)現(xiàn)細(xì)節(jié)上。5.3 靜態(tài)方法與構(gòu)造方法Mockito的老版本不支持mock靜態(tài)方法SpringBoot新版本里如果項(xiàng)目引用了mockito-inline就可以搞定try (MockedStaticIdGenerator mocked mockStatic(IdGenerator.class)) { mocked.when(() - IdGenerator.nextId()).thenReturn(42L); // 執(zhí)行被測代碼 }mockStatic返回的對象要記得關(guān)閉否則會(huì)影響同進(jìn)程里其他測試。一般用try-with-resources包住即可。對new出來的對象可以用mockConstruction但這兩個(gè)功能我建議盡量少用。遇到靜態(tài)方法調(diào)用優(yōu)先考慮通過注入接口來消除靜態(tài)依賴而不是依賴Mockito的擴(kuò)展能力。因?yàn)殪o態(tài)mock一旦用多測試會(huì)變得非常隱晦出問題也難排查。6. 真實(shí)數(shù)據(jù)庫聯(lián)測從H2到Testcontainers6.1 H2的甜蜜與陷阱DataJpaTest默認(rèn)會(huì)用H2代替真實(shí)數(shù)據(jù)庫如果項(xiàng)目用的是Hibernate大部分CRUD能正常跑通?？梢坏┥狭薓ySQL的方言特性H2就會(huì)開始背叛你。我在項(xiàng)目里遇到的典型問題包括H2對JSON類型的支持是模擬的序列化/反序列化行為跟MySQL不一致。MySQL的ON DUPLICATE KEY UPDATE在H2里是另一套語法。分頁查詢的LIMIT ? OFFSET ?表現(xiàn)有差異。字段默認(rèn)值、字符集排序規(guī)則不同可能導(dǎo)致測試通過但線上失敗。所以我的經(jīng)驗(yàn)是H2只適合驗(yàn)證查詢邏輯的雛形凡是涉及數(shù)據(jù)庫特性的項(xiàng)目真正該做的是用Testcontainers跑真實(shí)數(shù)據(jù)庫。6.2 Testcontainers 落地方式Testcontainers是一個(gè)極其好用的庫它能在測試時(shí)用Docker臨時(shí)拉起容器測試結(jié)束自動(dòng)銷毀保證環(huán)境干凈。SpringBoot生態(tài)里甚至有專門為它準(zhǔn)備的starterdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-testcontainers/artifactId scopetest/scope /dependency有了這個(gè)依賴測試?yán)锟梢赃@樣用Testcontainers class UserRepositoryDataJpaTest { Container static MySQLContainer? mysql new MySQLContainer(mysql:8.0.36) .withDatabaseName(test_db) .withUsername(test) .withPassword(test); // 通過動(dòng)態(tài)屬性注冊把數(shù)據(jù)源地址指到容器 DynamicPropertySource static void configureDatasource(DynamicPropertyRegistry registry) { registry.add(spring.datasource.url, mysql::getJdbcUrl); registry.add(spring.datasource.username, mysql::getUsername); registry.add(spring.datasource.password, mysql::getPassword); } }Container標(biāo)注的靜態(tài)字段只啟動(dòng)一次所有測試類共享同一套數(shù)據(jù)庫容器速度還能接受。DynamicPropertySource用來動(dòng)態(tài)注入配置比寫死application.yml里的連接地址要靈活得多。更省事的寫法是直接用JDBC URL里的tc:前綴這樣連Container都不用單獨(dú)聲明spring: datasource: url: jdbc:tc:mysql:8.0.36:///test_db driver-class-name: org.testcontainers.jdbc.ContainerDatabaseDriver這種玩法會(huì)自動(dòng)按URL拉起容器對已有代碼改動(dòng)最小。我最近幾個(gè)新項(xiàng)目都用的這個(gè)方式唯一需要保證的是CI機(jī)器上有可用的Docker環(huán)境。6.3 事務(wù)回滾與數(shù)據(jù)污染數(shù)據(jù)庫測試最大的敵人是數(shù)據(jù)污染。Spring對測試方法上有Transactional的方法是會(huì)默認(rèn)回滾的DataJpaTest本身也自帶這個(gè)行為。但如果測試?yán)镉玫氖荢pringBootTest想回滾就得自己加Transactional或者借助BeforeEach清理數(shù)據(jù)。我得提醒一個(gè)容易踩的坑測試方法里有異步操作或者數(shù)據(jù)庫操作發(fā)生在獨(dú)立線程時(shí)事務(wù)回滾會(huì)失效。比如Service里用了Async測試方法結(jié)束后異步線程還在寫數(shù)據(jù)回滾根本攔不住它。這也是為什么異步邏輯的測試要用真實(shí)數(shù)據(jù)庫加顯式清理或者用Mockito把異步邏輯改成同步執(zhí)行具體要看業(yè)務(wù)場景。另外Testcontainers容器雖然會(huì)銷毀但它拉起容器可能要花十幾秒。如果測試類特別多容器資源會(huì)互相占用。我建議給CI機(jī)器配置足夠的Docker資源或通過compose.yml的方式復(fù)用一套容器不要每個(gè)測試類都另起一個(gè)MySQL實(shí)例。7. 測試執(zhí)行效率與CI集成7.1 上下文緩存Spring的TestContext框架默認(rèn)會(huì)緩存應(yīng)用上下文只要配置相同多個(gè)測試類可以復(fù)用同一個(gè)上下文。這對性能影響巨大因?yàn)橐粋€(gè)全量SpringBootTest上下文可能耗時(shí)幾十秒復(fù)用后多個(gè)測試類共享一次啟動(dòng)成本。但緩存有幾個(gè)失效因素要特別注意MockBean或新版本的MockitoBean改變了上下文的定義用了不同mock的測試類會(huì)各自創(chuàng)建一根上下文。DynamicPropertySource會(huì)作為緩存key的一部分每個(gè)測試類如果注入不同的屬性緩存也失效。ContextConfiguration中的locations或initializers不同同樣會(huì)產(chǎn)生新上下文。所以在寫測試時(shí)我會(huì)盡量讓同一批測試的配置保持一致尤其是切片測試中聲明mock的方式不要一會(huì)兒一變。7.2 隨機(jī)測試帶來的確定性接口測試?yán)镒钆碌氖请S機(jī)性。比如測試依賴某個(gè)ID主鍵自增跑過一次后數(shù)據(jù)變了第二次執(zhí)行就失敗。解決辦法是不要讓測試依賴任何來自外部環(huán)境的可變值?？梢杂霉潭〝?shù)據(jù)、顯式清理、或者在斷言前先重置數(shù)據(jù)庫狀態(tài)。DirtiesContext這個(gè)注解我一般很謹(jǐn)慎地用。它會(huì)讓測試結(jié)束之后銷毀上下文下次再創(chuàng)建一個(gè)新的。這個(gè)成本非常高通常只在測試會(huì)修改Bean狀態(tài)、影響后續(xù)測試時(shí)才需要。如果是為了解決數(shù)據(jù)污染就上DirtiesContext那是用大炮打蚊子會(huì)導(dǎo)致整個(gè)測試套件變得奇慢無比。7.3 CI里怎么跑測試在CI里的運(yùn)行策略和本地不完全一樣。我一般把Maven Surefire配置成默認(rèn)跑所有單元測試和切片測試集成測試另用failsafe插件單獨(dú)跑放在發(fā)版管道里plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version configuration includes include**/*Test.java/include include**/*WebMvcTest.java/include include**/*DataJpaTest.java/include /includes excludes exclude**/*IntegrationTest.java/exclude /excludes /configuration /plugin對應(yīng)地集成測試類命名為XxxIntegrationTest交給failsafe插件去跑。這樣本地可以快速跑完單元測試CI的合并請求階段也不會(huì)被重量級集成測試拖慢。CI環(huán)境里還常見一個(gè)問題測試偶發(fā)失敗。偶發(fā)失敗比穩(wěn)定失敗更折磨人常見來源是端口沖突、外部服務(wù)超時(shí)、并發(fā)測試爭搶資源。我強(qiáng)烈建議把Surefire配置成parallel時(shí)只對無狀態(tài)的純單元測試開啟并行涉及容器或數(shù)據(jù)庫的測試不要并行否則排查成本比省下來的時(shí)間還高。8. 常見問題排查速查表最后整理一張我這些年攢下來的排查表基本上項(xiàng)目里踩過的測試坑都在這了。遇到問題先對著這張表查一遍很多坑可以直接跳過?，F(xiàn)象常見原因處理方式SpringBootTest啟動(dòng)失敗報(bào)數(shù)據(jù)源URL為空測試配置沒有正確覆蓋主配置確認(rèn)src/test/resources/application.yml存在且數(shù)據(jù)源配置完整測試方法內(nèi)開了事務(wù)但數(shù)據(jù)沒有被回滾方法里啟動(dòng)了新線程或調(diào)用了Async改用真實(shí)數(shù)據(jù)庫顯式清理或mock掉異步邏輯MockMvc測試報(bào)404WebMvcTest沒有包含目標(biāo)Controller在注解里顯式列出WebMvcTest(UserController.class)Mockito報(bào)UnnecessaryStubbingException打樁沒有被用到刪除多余的given(...)或使用lenient()Testcontainers起不來提示連接Docker失敗CI機(jī)器沒有Docker或Docker版本不兼容確保Docker daemon存活檢查測試機(jī)的socket權(quán)限D(zhuǎn)ataJpaTest中SQL語法錯(cuò)誤H2與MySQL方言不一致如果涉及數(shù)據(jù)庫特性切換Testcontainers真實(shí)數(shù)據(jù)庫測試之間數(shù)據(jù)相互污染沒有清理數(shù)據(jù)或事務(wù)回滾失效在每個(gè)用例前清理目標(biāo)數(shù)據(jù)表或使用Transactional保證回滾jsonPath($.data).value(...)一直失敗返回體結(jié)構(gòu)與預(yù)期不一致先用andReturn().getResponse().getContentAsString()打印返回體再比對測試上下文緩存未生效每次都重啟MockBean或DynamicPropertySource使用不一致導(dǎo)致緩存key變化盡量統(tǒng)一同一批測試類的mock聲明和配置注入排查時(shí)有個(gè)非常實(shí)用的招式別急著改代碼先看測試失敗時(shí)的完整日志和返回體。MockMvc測試失敗時(shí)經(jīng)常會(huì)打印完整的響應(yīng)內(nèi)容很多人忽略了這行輸出直接去翻生產(chǎn)代碼浪費(fèi)大量時(shí)間。我個(gè)人在實(shí)際操作中的體會(huì)是SpringBoot測試這事的核心并不在于會(huì)用幾個(gè)注解而在于建立起“分層驗(yàn)證、快慢分離、持續(xù)可跑”的測試?yán)砟睢淖畛醯腟pringBootTest一把梭到現(xiàn)在每層各司其職項(xiàng)目的回歸速度和質(zhì)量穩(wěn)定性都有了根本性的變化。這個(gè)內(nèi)容后續(xù)還可以繼續(xù)擴(kuò)展成一套團(tuán)隊(duì)內(nèi)部的測試規(guī)范文檔把切片選型、命名規(guī)范、容器管理、CI流水線配置都沉淀成模板讓每個(gè)新加入項(xiàng)目的同事都能少踩我踩過的那幾年坑。 SpringBoot測試分層實(shí)戰(zhàn)：MockMvc到Testcontainers
要說SpringBoot項(xiàng)目里最容易被敷衍對待的部分測試絕對排得上號。很多人寫測試就是給Service方法加個(gè)Test跑一下發(fā)現(xiàn)綠燈然后就沒有然后了。可等到接口被改、數(shù)據(jù)庫切換、并發(fā)上來之后最先崩潰的往往就是那堆形同虛設(shè)的測試。我早年也吃過這個(gè)虧后來才慢慢把一個(gè)SpringBoot項(xiàng)目的測試體系從“會(huì)跑”折騰到“能救命”。這篇文章就把我在實(shí)戰(zhàn)里沉淀下來的那套打法完整梳理一遍覆蓋從依賴選型、分層策略到MockMvc、Mockito、Testcontainers的落地細(xì)節(jié)以及那些文檔里不會(huì)寫的坑。1. 測試在SpringBoot項(xiàng)目里的定位與分層思路1.1 為什么SpringBoot測試常?！靶瓮撛O(shè)”很多項(xiàng)目的測試代碼看起來不少覆蓋率報(bào)表也好看但一遇到重構(gòu)就稀里嘩啦碎一地。我見過最常見的病根是把測試寫成了“實(shí)現(xiàn)細(xì)節(jié)的復(fù)讀機(jī)”。比如Service層剛調(diào)了userMapper測試?yán)锞蚼ock一堆when(userMapper.selectById()).thenReturn(...)然后斷言返回值。一旦把Mapper換成別的數(shù)據(jù)源測試全部紅掉可業(yè)務(wù)邏輯明明沒變。這種測試的問題在于它驗(yàn)證的是“代碼是怎么寫的”而不是“行為是否正確”。所以我在項(xiàng)目里反復(fù)強(qiáng)調(diào)一個(gè)原則測試要對著契約寫不要對著實(shí)現(xiàn)寫。接口的輸入輸出、異常規(guī)則、狀態(tài)流轉(zhuǎn)才是契約至于底層用的什么框架、什么ORM都不該是單測關(guān)心的重點(diǎn)。這個(gè)認(rèn)知不糾正后面所有工具和技術(shù)都是在錯(cuò)誤的路上加速。1.2 測試金字塔在SpringBoot里的落地方式測試金字塔這個(gè)概念不新鮮但在SpringBoot里落地時(shí)很多人會(huì)跑偏。理論上應(yīng)該是底層單元測試最多、中間集成測試適中、頂層端到端測試最少?？蓪?shí)際上因?yàn)镾pringBoot的SpringBootTest太方便了很多團(tuán)隊(duì)直接把所有測試都寫成全量上下文啟動(dòng)一個(gè)項(xiàng)目跑下來測試要十幾分鐘于是大家越來越不想寫測試。我在實(shí)踐中會(huì)把測試分成三類來管控單元測試針對Service、工具類、領(lǐng)域?qū)ο蟛粏?dòng)Spring容器用Mockito隔離依賴。切片測試只加載某一層需要的Bean比如WebMvcTest只加載Controller和MVC相關(guān)配置DataJpaTest只加載Repository和數(shù)據(jù)源相關(guān)配置。集成測試啟動(dòng)完整上下文必要時(shí)用Testcontainers拉起真實(shí)MySQL、Redis等中間件驗(yàn)證跨模塊交互。這三類的比例我會(huì)控制在7:2:1左右。單元測試和切片測試跑得快合并請求時(shí)全量執(zhí)行沒壓力集成測試數(shù)量少、價(jià)值高放在發(fā)版流水線里跑。1.3 一套可持續(xù)的測試策略長什么樣可持續(xù)的關(guān)鍵不是覆蓋率數(shù)字而是反饋速度和穩(wěn)定性的平衡。我見過太多測試綠了但其實(shí)是假綠原因無非是斷言寫得寬松、數(shù)據(jù)沒清理干凈、隨機(jī)端口沖突等等。所以我會(huì)給項(xiàng)目定幾個(gè)硬規(guī)矩所有測試必須能重復(fù)執(zhí)行跑十次結(jié)果一致不允許依賴執(zhí)行順序。測試之間不允許共享可變狀態(tài)數(shù)據(jù)庫、Redis、文件系統(tǒng)必須在每個(gè)用例結(jié)束后恢復(fù)。單元測試和切片測試總耗時(shí)控制在兩分鐘以內(nèi)超過就要拆分。任何測試失敗先解決測試本身不允許用Disabled掩蓋問題。這些規(guī)矩剛定的時(shí)候會(huì)有人覺得麻煩但堅(jiān)持下來之后測試是真的敢在發(fā)版前給人信心的。2. 測試環(huán)境搭建與依賴選型2.1 spring-boot-starter-test里都有什么SpringBoot的測試依賴非常省心起步就在pom.xml里加一個(gè)spring-boot-starter-testdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency這個(gè)starter做了很多底層整合不是簡單地把JUnit扔給你。它默認(rèn)帶了一套組合好的測試工具箱JUnit 5Jupiter現(xiàn)在的基礎(chǔ)測試框架Test、ParameterizedTest、RepeatedTest都靠它。Spring Test Context提供SpringBootTest、Transactional傳播、TestContextManager等能力。MockitoMock、InjectMocks、when/verify的核心來源。AssertJ流式斷言庫assertThat(...).isEqualTo(...)比JUnit原生的assertEquals可讀性好太多。Hamcrest老牌匹配器雖然AssertJ更常用但一些遺留代碼里還會(huì)見到。JSONassert用于對比JSON結(jié)構(gòu)接口測試斷言返回體時(shí)很有用。還有個(gè)容易被忽略的是spring-boot-test-autoconfigure所有WebMvcTest、DataJpaTest這類切片注解都來自它。它保證切片測試自動(dòng)裝配配置時(shí)不會(huì)誤加載其他層的Bean。需要單獨(dú)補(bǔ)依賴的話一般是加mockito-inline用于mock靜態(tài)方法和Testcontainers相關(guān)的模塊這個(gè)后面細(xì)說。2.2 測試目錄與命名規(guī)范目錄結(jié)構(gòu)直接用Maven/Gradle的標(biāo)準(zhǔn)test目錄就行我習(xí)慣把測試類按照被測試類的包結(jié)構(gòu)鏡像并且保持一套統(tǒng)一的命名規(guī)范團(tuán)隊(duì)成員看著不迷路Service層單元測試UserServiceTestController層切片測試UserControllerWebMvcTestRepository層切片測試UserRepositoryDataJpaTest集成測試UserServiceIntegrationTest命名這件事看起來細(xì)枝末節(jié)但作用非常大。跑測試的時(shí)候看到類名就知道它在測哪一層、需不需要容器環(huán)境排錯(cuò)效率直接翻倍。還有個(gè)小技巧把單元測試、切片測試、集成測試通過Maven Surefire的groups或命名后綴區(qū)分開方便在本地只跑某類測試。2.3 測試配置文件的隔離這是非常關(guān)鍵又容易被忽略的一環(huán)。application.yml里往往配置了真實(shí)環(huán)境或開發(fā)環(huán)境的數(shù)據(jù)源、緩存、消息隊(duì)列地址測試如果直接復(fù)用輕則連錯(cuò)庫重則把測試數(shù)據(jù)寫到生產(chǎn)環(huán)境旁邊的關(guān)系庫里去。我一般會(huì)建一個(gè)src/test/resources/application.yml用配置覆蓋的方式只保留測試需要的內(nèi)容spring: datasource: url: jdbc:tc:mysql:8.0.36:///test_db driver-class-name: org.testcontainers.jdbc.ContainerDatabaseDriver jpa: hibernate: ddl-auto: create-drop redis: host: localhost port: 16379注意這里的數(shù)據(jù)庫地址不是真實(shí)的MySQL地址而是Testcontainers的JDBC驅(qū)動(dòng)地址后面集成測試部分再展開。關(guān)鍵是要理解SpringBoot配置文件加載時(shí)有優(yōu)先級src/test/resources下的文件優(yōu)先級高于主目錄下的application.yml這樣測試項(xiàng)目可以放心覆蓋配置而不用改動(dòng)主代碼的配置。3. 容器測試與切片測試怎么選SpringBootTest用前先想清楚3.1 全量上下文啟動(dòng)的利與弊SpringBootTest是SpringBoot測試?yán)锏摹爸亓考夁x手”它的作用是啟動(dòng)完整的Spring容器把幾乎所有的Bean都裝配起來。好處是貼近真實(shí)運(yùn)行環(huán)境壞處也是顯而易見的啟動(dòng)一次要加載數(shù)據(jù)源、Redis連接、消息隊(duì)列、各種初始化邏輯一個(gè)中型項(xiàng)目跑單個(gè)測試可能就要十幾秒到幾十秒測試一多就完全跑不動(dòng)了。我見過一個(gè)項(xiàng)目光啟動(dòng)容器就要40秒90個(gè)測試類跑完接近一個(gè)小時(shí)。這個(gè)成本導(dǎo)致開發(fā)人員完全不想在本地跑測試最后測試形同虛設(shè)。所以我在新項(xiàng)目里對SpringBootTest的使用非常謹(jǐn)慎只有下面幾種場景才用它跨模塊的端到端業(yè)務(wù)鏈路驗(yàn)證比如從Controller入口一直打到數(shù)據(jù)庫。配置類的加載驗(yàn)證比如自定義的ConfigurationProperties是否綁定正確。需要完整容器環(huán)境的第三方對接聯(lián)調(diào)。其他場景能用切片就用切片。這個(gè)觀念轉(zhuǎn)變之后測試的反饋速度能提升一個(gè)數(shù)量級。3.2 切片測試更快但不是萬能SpringBoot為每個(gè)常見層次都提供了專門用于測試的注解。我這里先列幾個(gè)最常用的切片注解加載范圍典型用途W(wǎng)ebMvcTestController、Filter、ControllerAdvice、MVC配置不加載Service和Repository測試接口參數(shù)校驗(yàn)、路由映射、返回值結(jié)構(gòu)DataJpaTestRepository、Entity、數(shù)據(jù)源配置默認(rèn)使用內(nèi)嵌數(shù)據(jù)庫并開啟事務(wù)回滾測試倉儲(chǔ)層的CRUD、查詢規(guī)則、分頁排序JsonTestJackson/Gson的ObjectMapper相關(guān)配置測試JSON序列化和反序列化規(guī)則RestClientTestRestTemplateBuilder相關(guān)的RestClient配置測試遠(yuǎn)程HTTP客戶端調(diào)用邏輯MybatisTestMyBatis的Mapper和配置需引入第三方starter測試MyBatis的SQL語句映射WebMvcTest是我每天都會(huì)用到的。它只加載Web層Service用MockBean新版本里推薦MockitoBean或MockBean具體看Spring版本打樁。這樣啟動(dòng)速度非?？煲粋€(gè)Controller相關(guān)的測試類通常在幾百毫秒內(nèi)就能跑起來。不過切片測試也不是萬能藥。WebMvcTest不會(huì)加載你自定義的攔截器之外的全局配置如果攔截器依賴了Service里的數(shù)據(jù)就需要額外把相關(guān)Bean補(bǔ)進(jìn)測試上下文DataJpaTest默認(rèn)用內(nèi)嵌H2替換真實(shí)數(shù)據(jù)庫如果項(xiàng)目里用了MySQL特有的JSON字段或全文索引H2大概率模擬不出來這時(shí)候就得考慮Testcontainers。3.3 不同場景下的選型對照我在實(shí)際項(xiàng)目中形成了一張很實(shí)用的對照表每個(gè)新開發(fā)者進(jìn)來我都會(huì)先發(fā)這張表防止他們憑感覺選測試方式測試目標(biāo)推薦方式啟動(dòng)速度真實(shí)度是否要mockController參數(shù)校驗(yàn)、路由WebMvcTest快中mock ServiceService業(yè)務(wù)規(guī)則純JUnit Mockito極快低mock Repository/外部ClientRepository查詢邏輯DataJpaTest較快中取決于數(shù)據(jù)庫類型不需要跨層主流程SpringBootTestTransactional慢高看情況外部中間件真實(shí)聯(lián)測SpringBootTest Testcontainers慢極高一般不需要這個(gè)表格背后真正的判斷標(biāo)準(zhǔn)是三個(gè)問題測的是哪一層這層最關(guān)心的風(fēng)險(xiǎn)是什么需要多高的環(huán)境保真度想清楚這三個(gè)問題選型就不會(huì)錯(cuò)。4. Controller層測試實(shí)戰(zhàn)MockMvc的關(guān)鍵細(xì)節(jié)4.1 MockMvc 基本套路Controller層的測試最常用MockMvc配合WebMvcTest使用不需要真正啟動(dòng)Web容器。直接發(fā)起HTTP請求然后對返回的響應(yīng)做斷言。下面這段代碼是典型的用法WebMvcTest(UserController.class) class UserControllerWebMvcTest { Autowired private MockMvc mockMvc; MockBean private UserService userService; Test void shouldReturnUserWhenIdExists() throws Exception { UserVO mockUser new UserVO(1L, 張三, zhangsanexample.com); given(userService.findById(1L)).willReturn(mockUser); mockMvc.perform(get(/api/users/1) .accept(MediaType.APPLICATION_JSON)) .andExpect(status().isOk()) .andExpect(jsonPath($.name).value(張三)) .andExpect(jsonPath($.email).value(zhangsanexample.com)); } }given是Mockito BDD風(fēng)格的寫法等價(jià)于when(...).thenReturn(...)只是可讀性更好。很多人寫Controller測試時(shí)習(xí)慣直接調(diào)Controller的方法這樣其實(shí)繞過了路由解析、參數(shù)綁定、序列化這些真正的風(fēng)險(xiǎn)點(diǎn)測試價(jià)值大打折扣。用MockMvc走一趟完整請求鏈路才檔得住真實(shí)的調(diào)用問題。4.2 斷言比調(diào)用更重要測試的核心不是把請求發(fā)出去而是做足夠嚴(yán)謹(jǐn)?shù)臄嘌?。我見過不少同事寫完andExpect(status().isOk())就收工了根本沒驗(yàn)證返回內(nèi)容。這種測試跟沒寫差不多接口里面隨便改點(diǎn)東西都會(huì)照常綠。我給團(tuán)隊(duì)定的標(biāo)準(zhǔn)是至少覆蓋狀態(tài)碼status().isOk()、isCreated()、isBadRequest()等。業(yè)務(wù)字段用jsonPath逐一斷言核心字段不允許只斷一個(gè)$.code。關(guān)鍵時(shí)序涉及異步或重定向時(shí)檢查響應(yīng)頭里的Location或狀態(tài)流轉(zhuǎn)。異常路徑參數(shù)缺失、資源不存在、權(quán)限不足每一種都得有對應(yīng)的用例。JSONPath斷言是接口測試?yán)锏睦?。假設(shè)返回體是{data: {items: [{id: 2}, {id: 5}]}}可以這樣寫.andExpect(jsonPath($.data.items.length()).value(2)) .andExpect(jsonPath($.data.items[1].id).value(5))注意length()這個(gè)函數(shù)式寫法很多人在第一次接觸JSONPath時(shí)會(huì)漏掉導(dǎo)致斷言怎么寫都不對。4.3 常見翻車點(diǎn)我在接口測試?yán)锊冗^不少坑挑幾個(gè)典型分享MockBean的返回值類型不一致如果UserService.findById返回的是OptionalUserVO但代碼里處理的是null判斷mock時(shí)容易返回Optional.empty()而忘掉對應(yīng)邏輯分支然后測試通過的代碼拿真實(shí)數(shù)據(jù)就出問題。建議mock時(shí)先確認(rèn)生產(chǎn)代碼的判空路徑。日期時(shí)間格式LocalDateTime默認(rèn)序列化格式是數(shù)組比如[2025, 5, 1, 10, 30, 0]。如果接口要對前端返回yyyy-MM-dd HH:mm:ssController測試?yán)锉仨汄?yàn)證這個(gè)格式否則到聯(lián)調(diào)時(shí)才暴露就晚了。分頁參數(shù)的默認(rèn)值Spring Data的分頁接口如果沒傳page和size會(huì)走默認(rèn)值。測試?yán)锶绻粶y默認(rèn)值后面前端傳錯(cuò)參數(shù)也沒人發(fā)現(xiàn)。靜態(tài)資源處理WebMvcTest默認(rèn)不會(huì)加載靜態(tài)資源映射如果Controller里有重定向到靜態(tài)頁面的接口測試?yán)锟梢酝ㄟ^手動(dòng)添加資源處理器或者改用SpringBootTest。還有一點(diǎn)很多人不知道MockMvc的perform其實(shí)會(huì)在內(nèi)部走完整的DispatcherServlet所以Valid注解觸發(fā)的參數(shù)校驗(yàn)在WebMvcTest里是真實(shí)生效的。換句話說Controller層的參數(shù)校驗(yàn)測試完全可以在切片環(huán)境里做不需要跑到集成測試?yán)镌傺a(bǔ)。5. Service層單元測試Mockito的正確姿勢5.1 基礎(chǔ)三件套Service層是業(yè)務(wù)邏輯的聚集地測試價(jià)值最大但也是最容易被寫壞的。我常用的基礎(chǔ)模式是MockInjectMocksExtendWith(MockitoExtension.class) class UserServiceTest { Mock private UserRepository userRepository; Mock private PasswordEncoder passwordEncoder; InjectMocks private UserService userService; Test void shouldCreateUserWithEncodedPassword() { String rawPassword abc12345; given(passwordEncoder.encode(rawPassword)).willReturn(encoded-value); User created userService.createUser(zhangsan, rawPassword); assertThat(created.getPassword()).isEqualTo(encoded-value); verify(userRepository).save(any(User.class)); } }ExtendWith(MockitoExtension.class)是JUnit 5與Mockito集成的入口沒有它Mock和InjectMocks不會(huì)生效。InjectMocks會(huì)優(yōu)先按構(gòu)造器注入其次是setter和字段注入這要求被測類的依賴盡量通過構(gòu)造器聲明否則容易注入不進(jìn)去。5.2 別mock一切很多人寫Service測試時(shí)有個(gè)壞毛病把Service內(nèi)部依賴的私有方法也通過mock去繞開。實(shí)際上Mock只能作用于類的公開協(xié)作對象私有邏輯該測還是得測。更糟糕的是有些人會(huì)把UserRepository.save(...)的返回值mock成一個(gè)帶ID的復(fù)雜對象結(jié)果Service里后續(xù)依賴的字段沒設(shè)置測試和真實(shí)行為對不上。我踩過一次最深的坑是某個(gè)下單流程里OrderRepository.save()返回的訂單對象里有個(gè)凍結(jié)金額字段我mock的時(shí)候忘了set值導(dǎo)致后續(xù)計(jì)算一直為0測試卻綠了。上線后真實(shí)數(shù)據(jù)一跑就出狀況。那之后我定了個(gè)規(guī)則能少mock就少mock能走真實(shí)對象就走真實(shí)對象。Repository里的方法如果有清晰的返回規(guī)則我寧愿寫個(gè)真實(shí)的實(shí)體對象傳進(jìn)去也不想mock出個(gè)殘缺對象。另外verify經(jīng)常被用錯(cuò)。verify(userRepository).save(...)驗(yàn)證的是這個(gè)調(diào)用發(fā)生過一次但如果你想要的是“最終調(diào)用了兩次”這種次數(shù)斷言需要配合times(2)。不要濫用verifyNoMoreInteractions()它會(huì)把測試綁死在實(shí)現(xiàn)細(xì)節(jié)上。5.3 靜態(tài)方法與構(gòu)造方法Mockito的老版本不支持mock靜態(tài)方法SpringBoot新版本里如果項(xiàng)目引用了mockito-inline就可以搞定try (MockedStaticIdGenerator mocked mockStatic(IdGenerator.class)) { mocked.when(() - IdGenerator.nextId()).thenReturn(42L); // 執(zhí)行被測代碼 }mockStatic返回的對象要記得關(guān)閉否則會(huì)影響同進(jìn)程里其他測試。一般用try-with-resources包住即可。對new出來的對象可以用mockConstruction但這兩個(gè)功能我建議盡量少用。遇到靜態(tài)方法調(diào)用優(yōu)先考慮通過注入接口來消除靜態(tài)依賴而不是依賴Mockito的擴(kuò)展能力。因?yàn)殪o態(tài)mock一旦用多測試會(huì)變得非常隱晦出問題也難排查。6. 真實(shí)數(shù)據(jù)庫聯(lián)測從H2到Testcontainers6.1 H2的甜蜜與陷阱DataJpaTest默認(rèn)會(huì)用H2代替真實(shí)數(shù)據(jù)庫如果項(xiàng)目用的是Hibernate大部分CRUD能正常跑通?？梢坏┥狭薓ySQL的方言特性H2就會(huì)開始背叛你。我在項(xiàng)目里遇到的典型問題包括H2對JSON類型的支持是模擬的序列化/反序列化行為跟MySQL不一致。MySQL的ON DUPLICATE KEY UPDATE在H2里是另一套語法。分頁查詢的LIMIT ? OFFSET ?表現(xiàn)有差異。字段默認(rèn)值、字符集排序規(guī)則不同可能導(dǎo)致測試通過但線上失敗。所以我的經(jīng)驗(yàn)是H2只適合驗(yàn)證查詢邏輯的雛形凡是涉及數(shù)據(jù)庫特性的項(xiàng)目真正該做的是用Testcontainers跑真實(shí)數(shù)據(jù)庫。6.2 Testcontainers 落地方式Testcontainers是一個(gè)極其好用的庫它能在測試時(shí)用Docker臨時(shí)拉起容器測試結(jié)束自動(dòng)銷毀保證環(huán)境干凈。SpringBoot生態(tài)里甚至有專門為它準(zhǔn)備的starterdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-testcontainers/artifactId scopetest/scope /dependency有了這個(gè)依賴測試?yán)锟梢赃@樣用Testcontainers class UserRepositoryDataJpaTest { Container static MySQLContainer? mysql new MySQLContainer(mysql:8.0.36) .withDatabaseName(test_db) .withUsername(test) .withPassword(test); // 通過動(dòng)態(tài)屬性注冊把數(shù)據(jù)源地址指到容器 DynamicPropertySource static void configureDatasource(DynamicPropertyRegistry registry) { registry.add(spring.datasource.url, mysql::getJdbcUrl); registry.add(spring.datasource.username, mysql::getUsername); registry.add(spring.datasource.password, mysql::getPassword); } }Container標(biāo)注的靜態(tài)字段只啟動(dòng)一次所有測試類共享同一套數(shù)據(jù)庫容器速度還能接受。DynamicPropertySource用來動(dòng)態(tài)注入配置比寫死application.yml里的連接地址要靈活得多。更省事的寫法是直接用JDBC URL里的tc:前綴這樣連Container都不用單獨(dú)聲明spring: datasource: url: jdbc:tc:mysql:8.0.36:///test_db driver-class-name: org.testcontainers.jdbc.ContainerDatabaseDriver這種玩法會(huì)自動(dòng)按URL拉起容器對已有代碼改動(dòng)最小。我最近幾個(gè)新項(xiàng)目都用的這個(gè)方式唯一需要保證的是CI機(jī)器上有可用的Docker環(huán)境。6.3 事務(wù)回滾與數(shù)據(jù)污染數(shù)據(jù)庫測試最大的敵人是數(shù)據(jù)污染。Spring對測試方法上有Transactional的方法是會(huì)默認(rèn)回滾的DataJpaTest本身也自帶這個(gè)行為。但如果測試?yán)镉玫氖荢pringBootTest想回滾就得自己加Transactional或者借助BeforeEach清理數(shù)據(jù)。我得提醒一個(gè)容易踩的坑測試方法里有異步操作或者數(shù)據(jù)庫操作發(fā)生在獨(dú)立線程時(shí)事務(wù)回滾會(huì)失效。比如Service里用了Async測試方法結(jié)束后異步線程還在寫數(shù)據(jù)回滾根本攔不住它。這也是為什么異步邏輯的測試要用真實(shí)數(shù)據(jù)庫加顯式清理或者用Mockito把異步邏輯改成同步執(zhí)行具體要看業(yè)務(wù)場景。另外Testcontainers容器雖然會(huì)銷毀但它拉起容器可能要花十幾秒。如果測試類特別多容器資源會(huì)互相占用。我建議給CI機(jī)器配置足夠的Docker資源或通過compose.yml的方式復(fù)用一套容器不要每個(gè)測試類都另起一個(gè)MySQL實(shí)例。7. 測試執(zhí)行效率與CI集成7.1 上下文緩存Spring的TestContext框架默認(rèn)會(huì)緩存應(yīng)用上下文只要配置相同多個(gè)測試類可以復(fù)用同一個(gè)上下文。這對性能影響巨大因?yàn)橐粋€(gè)全量SpringBootTest上下文可能耗時(shí)幾十秒復(fù)用后多個(gè)測試類共享一次啟動(dòng)成本。但緩存有幾個(gè)失效因素要特別注意MockBean或新版本的MockitoBean改變了上下文的定義用了不同mock的測試類會(huì)各自創(chuàng)建一根上下文。DynamicPropertySource會(huì)作為緩存key的一部分每個(gè)測試類如果注入不同的屬性緩存也失效。ContextConfiguration中的locations或initializers不同同樣會(huì)產(chǎn)生新上下文。所以在寫測試時(shí)我會(huì)盡量讓同一批測試的配置保持一致尤其是切片測試中聲明mock的方式不要一會(huì)兒一變。7.2 隨機(jī)測試帶來的確定性接口測試?yán)镒钆碌氖请S機(jī)性。比如測試依賴某個(gè)ID主鍵自增跑過一次后數(shù)據(jù)變了第二次執(zhí)行就失敗。解決辦法是不要讓測試依賴任何來自外部環(huán)境的可變值?？梢杂霉潭〝?shù)據(jù)、顯式清理、或者在斷言前先重置數(shù)據(jù)庫狀態(tài)。DirtiesContext這個(gè)注解我一般很謹(jǐn)慎地用。它會(huì)讓測試結(jié)束之后銷毀上下文下次再創(chuàng)建一個(gè)新的。這個(gè)成本非常高通常只在測試會(huì)修改Bean狀態(tài)、影響后續(xù)測試時(shí)才需要。如果是為了解決數(shù)據(jù)污染就上DirtiesContext那是用大炮打蚊子會(huì)導(dǎo)致整個(gè)測試套件變得奇慢無比。7.3 CI里怎么跑測試在CI里的運(yùn)行策略和本地不完全一樣。我一般把Maven Surefire配置成默認(rèn)跑所有單元測試和切片測試集成測試另用failsafe插件單獨(dú)跑放在發(fā)版管道里plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version configuration includes include**/*Test.java/include include**/*WebMvcTest.java/include include**/*DataJpaTest.java/include /includes excludes exclude**/*IntegrationTest.java/exclude /excludes /configuration /plugin對應(yīng)地集成測試類命名為XxxIntegrationTest交給failsafe插件去跑。這樣本地可以快速跑完單元測試CI的合并請求階段也不會(huì)被重量級集成測試拖慢。CI環(huán)境里還常見一個(gè)問題測試偶發(fā)失敗。偶發(fā)失敗比穩(wěn)定失敗更折磨人常見來源是端口沖突、外部服務(wù)超時(shí)、并發(fā)測試爭搶資源。我強(qiáng)烈建議把Surefire配置成parallel時(shí)只對無狀態(tài)的純單元測試開啟并行涉及容器或數(shù)據(jù)庫的測試不要并行否則排查成本比省下來的時(shí)間還高。8. 常見問題排查速查表最后整理一張我這些年攢下來的排查表基本上項(xiàng)目里踩過的測試坑都在這了。遇到問題先對著這張表查一遍很多坑可以直接跳過?，F(xiàn)象常見原因處理方式SpringBootTest啟動(dòng)失敗報(bào)數(shù)據(jù)源URL為空測試配置沒有正確覆蓋主配置確認(rèn)src/test/resources/application.yml存在且數(shù)據(jù)源配置完整測試方法內(nèi)開了事務(wù)但數(shù)據(jù)沒有被回滾方法里啟動(dòng)了新線程或調(diào)用了Async改用真實(shí)數(shù)據(jù)庫顯式清理或mock掉異步邏輯MockMvc測試報(bào)404WebMvcTest沒有包含目標(biāo)Controller在注解里顯式列出WebMvcTest(UserController.class)Mockito報(bào)UnnecessaryStubbingException打樁沒有被用到刪除多余的given(...)或使用lenient()Testcontainers起不來提示連接Docker失敗CI機(jī)器沒有Docker或Docker版本不兼容確保Docker daemon存活檢查測試機(jī)的socket權(quán)限D(zhuǎn)ataJpaTest中SQL語法錯(cuò)誤H2與MySQL方言不一致如果涉及數(shù)據(jù)庫特性切換Testcontainers真實(shí)數(shù)據(jù)庫測試之間數(shù)據(jù)相互污染沒有清理數(shù)據(jù)或事務(wù)回滾失效在每個(gè)用例前清理目標(biāo)數(shù)據(jù)表或使用Transactional保證回滾jsonPath($.data).value(...)一直失敗返回體結(jié)構(gòu)與預(yù)期不一致先用andReturn().getResponse().getContentAsString()打印返回體再比對測試上下文緩存未生效每次都重啟MockBean或DynamicPropertySource使用不一致導(dǎo)致緩存key變化盡量統(tǒng)一同一批測試類的mock聲明和配置注入排查時(shí)有個(gè)非常實(shí)用的招式別急著改代碼先看測試失敗時(shí)的完整日志和返回體。MockMvc測試失敗時(shí)經(jīng)常會(huì)打印完整的響應(yīng)內(nèi)容很多人忽略了這行輸出直接去翻生產(chǎn)代碼浪費(fèi)大量時(shí)間。我個(gè)人在實(shí)際操作中的體會(huì)是SpringBoot測試這事的核心并不在于會(huì)用幾個(gè)注解而在于建立起“分層驗(yàn)證、快慢分離、持續(xù)可跑”的測試?yán)砟睢淖畛醯腟pringBootTest一把梭到現(xiàn)在每層各司其職項(xiàng)目的回歸速度和質(zhì)量穩(wěn)定性都有了根本性的變化。這個(gè)內(nèi)容后續(xù)還可以繼續(xù)擴(kuò)展成一套團(tuán)隊(duì)內(nèi)部的測試規(guī)范文檔把切片選型、命名規(guī)范、容器管理、CI流水線配置都沉淀成模板讓每個(gè)新加入項(xiàng)目的同事都能少踩我踩過的那幾年坑。