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