試分層實(shí)戰(zhàn)：MockMvc到Testcontainers)
要說(shuō)SpringBoot項(xiàng)目里最容易被敷衍對(duì)待的部分測(cè)試絕對(duì)排得上號(hào)。很多人寫(xiě)測(cè)試就是給Service方法加個(gè)Test跑一下發(fā)現(xiàn)綠燈然后就沒(méi)有然后了?？傻鹊浇涌诒桓?、數(shù)據(jù)庫(kù)切換、并發(fā)上來(lái)之后最先崩潰的往往就是那堆形同虛設(shè)的測(cè)試。我早年也吃過(guò)這個(gè)虧后來(lái)才慢慢把一個(gè)SpringBoot項(xiàng)目的測(cè)試體系從“會(huì)跑”折騰到“能救命”。這篇文章就把我在實(shí)戰(zhàn)里沉淀下來(lái)的那套打法完整梳理一遍覆蓋從依賴選型、分層策略到MockMvc、Mockito、Testcontainers的落地細(xì)節(jié)以及那些文檔里不會(huì)寫(xiě)的坑。1. 測(cè)試在SpringBoot項(xiàng)目里的定位與分層思路1.1 為什么SpringBoot測(cè)試常?！靶瓮撛O(shè)”很多項(xiàng)目的測(cè)試代碼看起來(lái)不少覆蓋率報(bào)表也好看但一遇到重構(gòu)就稀里嘩啦碎一地。我見(jiàn)過(guò)最常見(jiàn)的病根是把測(cè)試寫(xiě)成了“實(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ù)邏輯明明沒(méi)變。這種測(cè)試的問(wèn)題在于它驗(yàn)證的是“代碼是怎么寫(xiě)的”而不是“行為是否正確”。所以我在項(xiàng)目里反復(fù)強(qiáng)調(diào)一個(gè)原則測(cè)試要對(duì)著契約寫(xiě)不要對(duì)著實(shí)現(xiàn)寫(xiě)。接口的輸入輸出、異常規(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è)試都寫(xiě)成全量上下文啟動(dòng)一個(gè)項(xiàng)目跑下來(lái)測(cè)試要十幾分鐘于是大家越來(lái)越不想寫(xiě)測(cè)試。我在實(shí)踐中會(huì)把測(cè)試分成三類來(lái)管控單元測(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í)行沒(méi)壓力集成測(cè)試數(shù)量少、價(jià)值高放在發(fā)版流水線里跑。1.3 一套可持續(xù)的測(cè)試策略長(zhǎng)什么樣可持續(xù)的關(guān)鍵不是覆蓋率數(shù)字而是反饋速度和穩(wěn)定性的平衡。我見(jiàn)過(guò)太多測(cè)試綠了但其實(shí)是假綠原因無(wú)非是斷言寫(xiě)得寬松、數(shù)據(jù)沒(méi)清理干凈、隨機(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)超過(guò)就要拆分。任何測(cè)試失敗先解決測(cè)試本身不允許用Disabled掩蓋問(wèn)題。這些規(guī)矩剛定的時(shí)候會(huì)有人覺(jué)得麻煩但堅(jiān)持下來(lái)之后測(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的核心來(lái)源。AssertJ流式斷言庫(kù)assertThat(...).isEqualTo(...)比JUnit原生的assertEquals可讀性好太多。Hamcrest老牌匹配器雖然AssertJ更常用但一些遺留代碼里還會(huì)見(jiàn)到。JSONassert用于對(duì)比JSON結(jié)構(gòu)接口測(cè)試斷言返回體時(shí)很有用。還有個(gè)容易被忽略的是spring-boot-test-autoconfigure所有WebMvcTest、DataJpaTest這類切片注解都來(lái)自它。它保證切片測(cè)試自動(dòng)裝配配置時(shí)不會(huì)誤加載其他層的Bean。需要單獨(dú)補(bǔ)依賴的話一般是加mockito-inline用于mock靜態(tài)方法和Testcontainers相關(guān)的模塊這個(gè)后面細(xì)說(shuō)。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命名這件事看起來(lái)細(xì)枝末節(jié)但作用非常大。跑測(cè)試的時(shí)候看到類名就知道它在測(cè)哪一層、需不需要容器環(huán)境排錯(cuò)效率直接翻倍。還有個(gè)小技巧把單元測(cè)試、切片測(cè)試、集成測(cè)試通過(guò)Maven Surefire的groups或命名后綴區(qū)分開(kāi)方便在本地只跑某類測(cè)試。2.3 測(cè)試配置文件的隔離這是非常關(guān)鍵又容易被忽略的一環(huán)。application.yml里往往配置了真實(shí)環(huán)境或開(kāi)發(fā)環(huán)境的數(shù)據(jù)源、緩存、消息隊(duì)列地址測(cè)試如果直接復(fù)用輕則連錯(cuò)庫(kù)重則把測(cè)試數(shù)據(jù)寫(xiě)到生產(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è)試部分再展開(kāi)。關(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都裝配起來(lái)。好處是貼近真實(shí)運(yùn)行環(huán)境壞處也是顯而易見(jiàn)的啟動(dòng)一次要加載數(shù)據(jù)源、Redis連接、消息隊(duì)列、各種初始化邏輯一個(gè)中型項(xiàng)目跑單個(gè)測(cè)試可能就要十幾秒到幾十秒測(cè)試一多就完全跑不動(dòng)了。我見(jiàn)過(guò)一個(gè)項(xiàng)目光啟動(dòng)容器就要40秒90個(gè)測(cè)試類跑完接近一個(gè)小時(shí)。這個(gè)成本導(dǎo)致開(kāi)發(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è)試更快但不是萬(wàn)能SpringBoot為每個(gè)常見(jiàn)層次都提供了專門(mén)用于測(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ù)并開(kāi)啟事務(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語(yǔ)句映射WebMvcTest是我每天都會(huì)用到的。它只加載Web層Service用MockBean新版本里推薦MockitoBean或MockBean具體看Spring版本打樁。這樣啟動(dòng)速度非?？煲粋€(gè)Controller相關(guān)的測(cè)試類通常在幾百毫秒內(nèi)就能跑起來(lái)。不過(guò)切片測(cè)試也不是萬(wàn)能藥。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大概率模擬不出來(lái)這時(shí)候就得考慮Testcontainers。3.3 不同場(chǎng)景下的選型對(duì)照我在實(shí)際項(xiàng)目中形成了一張很實(shí)用的對(duì)照表每個(gè)新開(kāi)發(fā)者進(jìn)來(lái)我都會(huì)先發(fā)這張表防止他們憑感覺(jué)選測(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è)問(wèn)題測(cè)的是哪一層這層最關(guān)心的風(fēng)險(xiǎn)是什么需要多高的環(huán)境保真度想清楚這三個(gè)問(wèn)題選型就不會(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)格的寫(xiě)法等價(jià)于when(...).thenReturn(...)只是可讀性更好。很多人寫(xiě)Controller測(cè)試時(shí)習(xí)慣直接調(diào)Controller的方法這樣其實(shí)繞過(guò)了路由解析、參數(shù)綁定、序列化這些真正的風(fēng)險(xiǎn)點(diǎn)測(cè)試價(jià)值大打折扣。用MockMvc走一趟完整請(qǐng)求鏈路才檔得住真實(shí)的調(diào)用問(wèn)題。4.2 斷言比調(diào)用更重要測(cè)試的核心不是把請(qǐng)求發(fā)出去而是做足夠嚴(yán)謹(jǐn)?shù)臄嘌?。我?jiàn)過(guò)不少同事寫(xiě)完andExpect(status().isOk())就收工了根本沒(méi)驗(yàn)證返回內(nèi)容。這種測(cè)試跟沒(méi)寫(xiě)差不多接口里面隨便改點(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}]}}可以這樣寫(xiě).andExpect(jsonPath($.data.items.length()).value(2)) .andExpect(jsonPath($.data.items[1].id).value(5))注意length()這個(gè)函數(shù)式寫(xiě)法很多人在第一次接觸JSONPath時(shí)會(huì)漏掉導(dǎo)致斷言怎么寫(xiě)都不對(duì)。4.3 常見(jiàn)翻車點(diǎn)我在接口測(cè)試?yán)锊冗^(guò)不少坑挑幾個(gè)典型分享MockBean的返回值類型不一致如果UserService.findById返回的是OptionalUserVO但代碼里處理的是null判斷mock時(shí)容易返回Optional.empty()而忘掉對(duì)應(yīng)邏輯分支然后測(cè)試通過(guò)的代碼拿真實(shí)數(shù)據(jù)就出問(wèn)題。建議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è)接口如果沒(méi)傳page和size會(huì)走默認(rèn)值。測(cè)試?yán)锶绻粶y(cè)默認(rèn)值后面前端傳錯(cuò)參數(shù)也沒(méi)人發(fā)現(xiàn)。靜態(tài)資源處理WebMvcTest默認(rèn)不會(huì)加載靜態(tài)資源映射如果Controller里有重定向到靜態(tài)頁(yè)面的接口測(cè)試?yán)锟梢酝ㄟ^(guò)手動(dòng)添加資源處理器或者改用SpringBootTest。還有一點(diǎn)很多人不知道MockMvc的perform其實(shí)會(huì)在內(nèi)部走完整的DispatcherServlet所以Valid注解觸發(fā)的參數(shù)校驗(yàn)在WebMvcTest里是真實(shí)生效的。換句話說(shuō)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à)值最大但也是最容易被寫(xiě)壞的。我常用的基礎(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集成的入口沒(méi)有它Mock和InjectMocks不會(huì)生效。InjectMocks會(huì)優(yōu)先按構(gòu)造器注入其次是setter和字段注入這要求被測(cè)類的依賴盡量通過(guò)構(gòu)造器聲明否則容易注入不進(jìn)去。5.2 別mock一切很多人寫(xiě)Service測(cè)試時(shí)有個(gè)壞毛病把Service內(nèi)部依賴的私有方法也通過(guò)mock去繞開(kāi)。實(shí)際上Mock只能作用于類的公開(kāi)協(xié)作對(duì)象私有邏輯該測(cè)還是得測(cè)。更糟糕的是有些人會(huì)把UserRepository.save(...)的返回值mock成一個(gè)帶ID的復(fù)雜對(duì)象結(jié)果Service里后續(xù)依賴的字段沒(méi)設(shè)置測(cè)試和真實(shí)行為對(duì)不上。我踩過(guò)一次最深的坑是某個(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ī)則我寧愿寫(xiě)個(gè)真實(shí)的實(shí)體對(duì)象傳進(jìn)去也不想mock出個(gè)殘缺對(duì)象。另外verify經(jīng)常被用錯(cuò)。verify(userRepository).save(...)驗(yàn)證的是這個(gè)調(diào)用發(fā)生過(guò)一次但如果你想要的是“最終調(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出來(lái)的對(duì)象可以用mockConstruction但這兩個(gè)功能我建議盡量少用。遇到靜態(tài)方法調(diào)用優(yōu)先考慮通過(guò)注入接口來(lái)消除靜態(tài)依賴而不是依賴Mockito的擴(kuò)展能力。因?yàn)殪o態(tài)mock一旦用多測(cè)試會(huì)變得非常隱晦出問(wèn)題也難排查。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ì)開(kāi)始背叛你。我在項(xiàng)目里遇到的典型問(wèn)題包括H2對(duì)JSON類型的支持是模擬的序列化/反序列化行為跟MySQL不一致。MySQL的ON DUPLICATE KEY UPDATE在H2里是另一套語(yǔ)法。分頁(yè)查詢的LIMIT ? OFFSET ?表現(xiàn)有差異。字段默認(rèn)值、字符集排序規(guī)則不同可能導(dǎo)致測(cè)試通過(guò)但線上失敗。所以我的經(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)里甚至有專門(mén)為它準(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); // 通過(guò)動(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用來(lái)動(dòng)態(tài)注入配置比寫(xiě)死application.yml里的連接地址要靈活得多。更省事的寫(xiě)法是直接用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é)束后異步線程還在寫(xiě)數(shù)據(jù)回滾根本攔不住它。這也是為什么異步邏輯的測(cè)試要用真實(shí)數(shù)據(jù)庫(kù)加顯式清理或者用Mockito把異步邏輯改成同步執(zhí)行具體要看業(yè)務(wù)場(chǎng)景。另外Testcontainers容器雖然會(huì)銷毀但它拉起容器可能要花十幾秒。如果測(cè)試類特別多容器資源會(huì)互相占用。我建議給CI機(jī)器配置足夠的Docker資源或通過(guò)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)生新上下文。所以在寫(xiě)測(cè)試時(shí)我會(huì)盡量讓同一批測(cè)試的配置保持一致尤其是切片測(cè)試中聲明mock的方式不要一會(huì)兒一變。7.2 隨機(jī)測(cè)試帶來(lái)的確定性接口測(cè)試?yán)镒钆碌氖请S機(jī)性。比如測(cè)試依賴某個(gè)ID主鍵自增跑過(guò)一次后數(shù)據(jù)變了第二次執(zhí)行就失敗。解決辦法是不要讓測(cè)試依賴任何來(lái)自外部環(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è)試套件變得奇慢無(wú)比。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)境里還常見(jiàn)一個(gè)問(wèn)題測(cè)試偶發(fā)失敗。偶發(fā)失敗比穩(wěn)定失敗更折磨人常見(jiàn)來(lái)源是端口沖突、外部服務(wù)超時(shí)、并發(fā)測(cè)試爭(zhēng)搶資源。我強(qiáng)烈建議把Surefire配置成parallel時(shí)只對(duì)無(wú)狀態(tài)的純單元測(cè)試開(kāi)啟并行涉及容器或數(shù)據(jù)庫(kù)的測(cè)試不要并行否則排查成本比省下來(lái)的時(shí)間還高。8. 常見(jiàn)問(wèn)題排查速查表最后整理一張我這些年攢下來(lái)的排查表基本上項(xiàng)目里踩過(guò)的測(cè)試坑都在這了。遇到問(wèn)題先對(duì)著這張表查一遍很多坑可以直接跳過(guò)。現(xiàn)象常見(jiàn)原因處理方式SpringBootTest啟動(dòng)失敗報(bào)數(shù)據(jù)源URL為空測(cè)試配置沒(méi)有正確覆蓋主配置確認(rèn)src/test/resources/application.yml存在且數(shù)據(jù)源配置完整測(cè)試方法內(nèi)開(kāi)了事務(wù)但數(shù)據(jù)沒(méi)有被回滾方法里啟動(dòng)了新線程或調(diào)用了Async改用真實(shí)數(shù)據(jù)庫(kù)顯式清理或mock掉異步邏輯MockMvc測(cè)試報(bào)404WebMvcTest沒(méi)有包含目標(biāo)Controller在注解里顯式列出WebMvcTest(UserController.class)Mockito報(bào)UnnecessaryStubbingException打樁沒(méi)有被用到刪除多余的given(...)或使用lenient()Testcontainers起不來(lái)提示連接Docker失敗CI機(jī)器沒(méi)有Docker或Docker版本不兼容確保Docker daemon存活檢查測(cè)試機(jī)的socket權(quán)限D(zhuǎn)ataJpaTest中SQL語(yǔ)法錯(cuò)誤H2與MySQL方言不一致如果涉及數(shù)據(jù)庫(kù)特性切換Testcontainers真實(shí)數(shù)據(jù)庫(kù)測(cè)試之間數(shù)據(jù)相互污染沒(méi)有清理數(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)砟睢淖畛醯腟pringBootTest一把梭到現(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)目的同事都能少踩我踩過(guò)的那幾年坑。 SpringBoot測(cè)試分層實(shí)戰(zhàn)：MockMvc到Testcontainers
要說(shuō)SpringBoot項(xiàng)目里最容易被敷衍對(duì)待的部分測(cè)試絕對(duì)排得上號(hào)。很多人寫(xiě)測(cè)試就是給Service方法加個(gè)Test跑一下發(fā)現(xiàn)綠燈然后就沒(méi)有然后了?？傻鹊浇涌诒桓?、數(shù)據(jù)庫(kù)切換、并發(fā)上來(lái)之后最先崩潰的往往就是那堆形同虛設(shè)的測(cè)試。我早年也吃過(guò)這個(gè)虧后來(lái)才慢慢把一個(gè)SpringBoot項(xiàng)目的測(cè)試體系從“會(huì)跑”折騰到“能救命”。這篇文章就把我在實(shí)戰(zhàn)里沉淀下來(lái)的那套打法完整梳理一遍覆蓋從依賴選型、分層策略到MockMvc、Mockito、Testcontainers的落地細(xì)節(jié)以及那些文檔里不會(huì)寫(xiě)的坑。1. 測(cè)試在SpringBoot項(xiàng)目里的定位與分層思路1.1 為什么SpringBoot測(cè)試常?！靶瓮撛O(shè)”很多項(xiàng)目的測(cè)試代碼看起來(lái)不少覆蓋率報(bào)表也好看但一遇到重構(gòu)就稀里嘩啦碎一地。我見(jiàn)過(guò)最常見(jiàn)的病根是把測(cè)試寫(xiě)成了“實(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ù)邏輯明明沒(méi)變。這種測(cè)試的問(wèn)題在于它驗(yàn)證的是“代碼是怎么寫(xiě)的”而不是“行為是否正確”。所以我在項(xiàng)目里反復(fù)強(qiáng)調(diào)一個(gè)原則測(cè)試要對(duì)著契約寫(xiě)不要對(duì)著實(shí)現(xiàn)寫(xiě)。接口的輸入輸出、異常規(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è)試都寫(xiě)成全量上下文啟動(dòng)一個(gè)項(xiàng)目跑下來(lái)測(cè)試要十幾分鐘于是大家越來(lái)越不想寫(xiě)測(cè)試。我在實(shí)踐中會(huì)把測(cè)試分成三類來(lái)管控單元測(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í)行沒(méi)壓力集成測(cè)試數(shù)量少、價(jià)值高放在發(fā)版流水線里跑。1.3 一套可持續(xù)的測(cè)試策略長(zhǎng)什么樣可持續(xù)的關(guān)鍵不是覆蓋率數(shù)字而是反饋速度和穩(wěn)定性的平衡。我見(jiàn)過(guò)太多測(cè)試綠了但其實(shí)是假綠原因無(wú)非是斷言寫(xiě)得寬松、數(shù)據(jù)沒(méi)清理干凈、隨機(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)超過(guò)就要拆分。任何測(cè)試失敗先解決測(cè)試本身不允許用Disabled掩蓋問(wèn)題。這些規(guī)矩剛定的時(shí)候會(huì)有人覺(jué)得麻煩但堅(jiān)持下來(lái)之后測(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的核心來(lái)源。AssertJ流式斷言庫(kù)assertThat(...).isEqualTo(...)比JUnit原生的assertEquals可讀性好太多。Hamcrest老牌匹配器雖然AssertJ更常用但一些遺留代碼里還會(huì)見(jiàn)到。JSONassert用于對(duì)比JSON結(jié)構(gòu)接口測(cè)試斷言返回體時(shí)很有用。還有個(gè)容易被忽略的是spring-boot-test-autoconfigure所有WebMvcTest、DataJpaTest這類切片注解都來(lái)自它。它保證切片測(cè)試自動(dòng)裝配配置時(shí)不會(huì)誤加載其他層的Bean。需要單獨(dú)補(bǔ)依賴的話一般是加mockito-inline用于mock靜態(tài)方法和Testcontainers相關(guān)的模塊這個(gè)后面細(xì)說(shuō)。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命名這件事看起來(lái)細(xì)枝末節(jié)但作用非常大。跑測(cè)試的時(shí)候看到類名就知道它在測(cè)哪一層、需不需要容器環(huán)境排錯(cuò)效率直接翻倍。還有個(gè)小技巧把單元測(cè)試、切片測(cè)試、集成測(cè)試通過(guò)Maven Surefire的groups或命名后綴區(qū)分開(kāi)方便在本地只跑某類測(cè)試。2.3 測(cè)試配置文件的隔離這是非常關(guān)鍵又容易被忽略的一環(huán)。application.yml里往往配置了真實(shí)環(huán)境或開(kāi)發(fā)環(huán)境的數(shù)據(jù)源、緩存、消息隊(duì)列地址測(cè)試如果直接復(fù)用輕則連錯(cuò)庫(kù)重則把測(cè)試數(shù)據(jù)寫(xiě)到生產(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è)試部分再展開(kāi)。關(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都裝配起來(lái)。好處是貼近真實(shí)運(yùn)行環(huán)境壞處也是顯而易見(jiàn)的啟動(dòng)一次要加載數(shù)據(jù)源、Redis連接、消息隊(duì)列、各種初始化邏輯一個(gè)中型項(xiàng)目跑單個(gè)測(cè)試可能就要十幾秒到幾十秒測(cè)試一多就完全跑不動(dòng)了。我見(jiàn)過(guò)一個(gè)項(xiàng)目光啟動(dòng)容器就要40秒90個(gè)測(cè)試類跑完接近一個(gè)小時(shí)。這個(gè)成本導(dǎo)致開(kāi)發(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è)試更快但不是萬(wàn)能SpringBoot為每個(gè)常見(jiàn)層次都提供了專門(mén)用于測(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ù)并開(kāi)啟事務(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語(yǔ)句映射WebMvcTest是我每天都會(huì)用到的。它只加載Web層Service用MockBean新版本里推薦MockitoBean或MockBean具體看Spring版本打樁。這樣啟動(dòng)速度非?？煲粋€(gè)Controller相關(guān)的測(cè)試類通常在幾百毫秒內(nèi)就能跑起來(lái)。不過(guò)切片測(cè)試也不是萬(wàn)能藥。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大概率模擬不出來(lái)這時(shí)候就得考慮Testcontainers。3.3 不同場(chǎng)景下的選型對(duì)照我在實(shí)際項(xiàng)目中形成了一張很實(shí)用的對(duì)照表每個(gè)新開(kāi)發(fā)者進(jìn)來(lái)我都會(huì)先發(fā)這張表防止他們憑感覺(jué)選測(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è)問(wèn)題測(cè)的是哪一層這層最關(guān)心的風(fēng)險(xiǎn)是什么需要多高的環(huán)境保真度想清楚這三個(gè)問(wèn)題選型就不會(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)格的寫(xiě)法等價(jià)于when(...).thenReturn(...)只是可讀性更好。很多人寫(xiě)Controller測(cè)試時(shí)習(xí)慣直接調(diào)Controller的方法這樣其實(shí)繞過(guò)了路由解析、參數(shù)綁定、序列化這些真正的風(fēng)險(xiǎn)點(diǎn)測(cè)試價(jià)值大打折扣。用MockMvc走一趟完整請(qǐng)求鏈路才檔得住真實(shí)的調(diào)用問(wèn)題。4.2 斷言比調(diào)用更重要測(cè)試的核心不是把請(qǐng)求發(fā)出去而是做足夠嚴(yán)謹(jǐn)?shù)臄嘌?。我?jiàn)過(guò)不少同事寫(xiě)完andExpect(status().isOk())就收工了根本沒(méi)驗(yàn)證返回內(nèi)容。這種測(cè)試跟沒(méi)寫(xiě)差不多接口里面隨便改點(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}]}}可以這樣寫(xiě).andExpect(jsonPath($.data.items.length()).value(2)) .andExpect(jsonPath($.data.items[1].id).value(5))注意length()這個(gè)函數(shù)式寫(xiě)法很多人在第一次接觸JSONPath時(shí)會(huì)漏掉導(dǎo)致斷言怎么寫(xiě)都不對(duì)。4.3 常見(jiàn)翻車點(diǎn)我在接口測(cè)試?yán)锊冗^(guò)不少坑挑幾個(gè)典型分享MockBean的返回值類型不一致如果UserService.findById返回的是OptionalUserVO但代碼里處理的是null判斷mock時(shí)容易返回Optional.empty()而忘掉對(duì)應(yīng)邏輯分支然后測(cè)試通過(guò)的代碼拿真實(shí)數(shù)據(jù)就出問(wèn)題。建議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è)接口如果沒(méi)傳page和size會(huì)走默認(rèn)值。測(cè)試?yán)锶绻粶y(cè)默認(rèn)值后面前端傳錯(cuò)參數(shù)也沒(méi)人發(fā)現(xiàn)。靜態(tài)資源處理WebMvcTest默認(rèn)不會(huì)加載靜態(tài)資源映射如果Controller里有重定向到靜態(tài)頁(yè)面的接口測(cè)試?yán)锟梢酝ㄟ^(guò)手動(dòng)添加資源處理器或者改用SpringBootTest。還有一點(diǎn)很多人不知道MockMvc的perform其實(shí)會(huì)在內(nèi)部走完整的DispatcherServlet所以Valid注解觸發(fā)的參數(shù)校驗(yàn)在WebMvcTest里是真實(shí)生效的。換句話說(shuō)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à)值最大但也是最容易被寫(xiě)壞的。我常用的基礎(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集成的入口沒(méi)有它Mock和InjectMocks不會(huì)生效。InjectMocks會(huì)優(yōu)先按構(gòu)造器注入其次是setter和字段注入這要求被測(cè)類的依賴盡量通過(guò)構(gòu)造器聲明否則容易注入不進(jìn)去。5.2 別mock一切很多人寫(xiě)Service測(cè)試時(shí)有個(gè)壞毛病把Service內(nèi)部依賴的私有方法也通過(guò)mock去繞開(kāi)。實(shí)際上Mock只能作用于類的公開(kāi)協(xié)作對(duì)象私有邏輯該測(cè)還是得測(cè)。更糟糕的是有些人會(huì)把UserRepository.save(...)的返回值mock成一個(gè)帶ID的復(fù)雜對(duì)象結(jié)果Service里后續(xù)依賴的字段沒(méi)設(shè)置測(cè)試和真實(shí)行為對(duì)不上。我踩過(guò)一次最深的坑是某個(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ī)則我寧愿寫(xiě)個(gè)真實(shí)的實(shí)體對(duì)象傳進(jìn)去也不想mock出個(gè)殘缺對(duì)象。另外verify經(jīng)常被用錯(cuò)。verify(userRepository).save(...)驗(yàn)證的是這個(gè)調(diào)用發(fā)生過(guò)一次但如果你想要的是“最終調(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出來(lái)的對(duì)象可以用mockConstruction但這兩個(gè)功能我建議盡量少用。遇到靜態(tài)方法調(diào)用優(yōu)先考慮通過(guò)注入接口來(lái)消除靜態(tài)依賴而不是依賴Mockito的擴(kuò)展能力。因?yàn)殪o態(tài)mock一旦用多測(cè)試會(huì)變得非常隱晦出問(wèn)題也難排查。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ì)開(kāi)始背叛你。我在項(xiàng)目里遇到的典型問(wèn)題包括H2對(duì)JSON類型的支持是模擬的序列化/反序列化行為跟MySQL不一致。MySQL的ON DUPLICATE KEY UPDATE在H2里是另一套語(yǔ)法。分頁(yè)查詢的LIMIT ? OFFSET ?表現(xiàn)有差異。字段默認(rèn)值、字符集排序規(guī)則不同可能導(dǎo)致測(cè)試通過(guò)但線上失敗。所以我的經(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)里甚至有專門(mén)為它準(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); // 通過(guò)動(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用來(lái)動(dòng)態(tài)注入配置比寫(xiě)死application.yml里的連接地址要靈活得多。更省事的寫(xiě)法是直接用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é)束后異步線程還在寫(xiě)數(shù)據(jù)回滾根本攔不住它。這也是為什么異步邏輯的測(cè)試要用真實(shí)數(shù)據(jù)庫(kù)加顯式清理或者用Mockito把異步邏輯改成同步執(zhí)行具體要看業(yè)務(wù)場(chǎng)景。另外Testcontainers容器雖然會(huì)銷毀但它拉起容器可能要花十幾秒。如果測(cè)試類特別多容器資源會(huì)互相占用。我建議給CI機(jī)器配置足夠的Docker資源或通過(guò)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)生新上下文。所以在寫(xiě)測(cè)試時(shí)我會(huì)盡量讓同一批測(cè)試的配置保持一致尤其是切片測(cè)試中聲明mock的方式不要一會(huì)兒一變。7.2 隨機(jī)測(cè)試帶來(lái)的確定性接口測(cè)試?yán)镒钆碌氖请S機(jī)性。比如測(cè)試依賴某個(gè)ID主鍵自增跑過(guò)一次后數(shù)據(jù)變了第二次執(zhí)行就失敗。解決辦法是不要讓測(cè)試依賴任何來(lái)自外部環(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è)試套件變得奇慢無(wú)比。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)境里還常見(jiàn)一個(gè)問(wèn)題測(cè)試偶發(fā)失敗。偶發(fā)失敗比穩(wěn)定失敗更折磨人常見(jiàn)來(lái)源是端口沖突、外部服務(wù)超時(shí)、并發(fā)測(cè)試爭(zhēng)搶資源。我強(qiáng)烈建議把Surefire配置成parallel時(shí)只對(duì)無(wú)狀態(tài)的純單元測(cè)試開(kāi)啟并行涉及容器或數(shù)據(jù)庫(kù)的測(cè)試不要并行否則排查成本比省下來(lái)的時(shí)間還高。8. 常見(jiàn)問(wèn)題排查速查表最后整理一張我這些年攢下來(lái)的排查表基本上項(xiàng)目里踩過(guò)的測(cè)試坑都在這了。遇到問(wèn)題先對(duì)著這張表查一遍很多坑可以直接跳過(guò)。現(xiàn)象常見(jiàn)原因處理方式SpringBootTest啟動(dòng)失敗報(bào)數(shù)據(jù)源URL為空測(cè)試配置沒(méi)有正確覆蓋主配置確認(rèn)src/test/resources/application.yml存在且數(shù)據(jù)源配置完整測(cè)試方法內(nèi)開(kāi)了事務(wù)但數(shù)據(jù)沒(méi)有被回滾方法里啟動(dòng)了新線程或調(diào)用了Async改用真實(shí)數(shù)據(jù)庫(kù)顯式清理或mock掉異步邏輯MockMvc測(cè)試報(bào)404WebMvcTest沒(méi)有包含目標(biāo)Controller在注解里顯式列出WebMvcTest(UserController.class)Mockito報(bào)UnnecessaryStubbingException打樁沒(méi)有被用到刪除多余的given(...)或使用lenient()Testcontainers起不來(lái)提示連接Docker失敗CI機(jī)器沒(méi)有Docker或Docker版本不兼容確保Docker daemon存活檢查測(cè)試機(jī)的socket權(quán)限D(zhuǎn)ataJpaTest中SQL語(yǔ)法錯(cuò)誤H2與MySQL方言不一致如果涉及數(shù)據(jù)庫(kù)特性切換Testcontainers真實(shí)數(shù)據(jù)庫(kù)測(cè)試之間數(shù)據(jù)相互污染沒(méi)有清理數(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)砟睢淖畛醯腟pringBootTest一把梭到現(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)目的同事都能少踩我踩過(guò)的那幾年坑。