服务端开发

Appearance

MockMvc 与 AssertJ 集成：让测试更优雅 🎯 ​

概述 ​

在 Spring Boot 的测试世界中，MockMvc 是我们进行 Web 层测试的得力助手。而当它遇上 AssertJ 这个强大的断言库时，就像是给测试代码装上了涡轮增压器 🚀。本文将深入探讨如何将这两个工具完美融合，让你的测试代码既强大又优雅。

NOTE

MockMvcTester 是 Spring Framework 6.1+ 引入的新特性，它将 MockMvc 的功能与 AssertJ 的流畅断言风格完美结合。

为什么需要这种集成？ 🤔 ​

传统 MockMvc 的痛点 ​

在传统的 MockMvc 测试中，我们经常会遇到这样的代码：

kotlin
// 传统的 MockMvc 测试方式
mockMvc.perform(get("/hotels/{id}", 42))
    .andExpect(status().isOk())
    .andExpect(content().contentType(MediaType.APPLICATION_JSON))
    .andExpect(jsonPath("$.name").value("Grand Hotel"))
    .andExpect(jsonPath("$.rooms").value(100))
kotlin
// 使用 AssertJ 集成后的优雅方式
assertThat(mockMvc.get().uri("/hotels/{id}", 42))
    .hasStatusOk()
    .hasContentType(MediaType.APPLICATION_JSON)
    .bodyJson()
    .extractingPath("$.name").isEqualTo("Grand Hotel")
    .extractingPath("$.rooms").isEqualTo(100)

TIP

可以看出，AssertJ 集成方式提供了更加流畅和直观的 API，让测试代码的可读性大大提升！

核心集成方式 ​

1. 使用现有的 RequestBuilder ​

如果你已经投资了原始的 MockMvc API，并且有自己的 RequestBuilder 实现，MockMvcTester 提供了 perform 方法来无缝集成：

kotlin
@SpringBootTest
@AutoConfigureTestDatabase
class HotelControllerIntegrationTest {
    
    @Autowired
    private lateinit var mockMvc: MockMvcTester
    
    @Test
    fun `should get hotel by id using existing RequestBuilder`() {
        // 使用传统的 RequestBuilder，但享受 AssertJ 的断言风格
        assertThat(mockMvc.perform(get("/hotels/{id}", 42))) 
            .hasStatusOk()
            .hasContentType(MediaType.APPLICATION_JSON)
            .bodyJson()
            .extractingPath("$.name").isEqualTo("Grand Hotel")
    }
}

IMPORTANT

这种方式特别适合那些已经有大量现有测试代码的项目，可以渐进式地迁移到新的断言风格。

2. 复用自定义的 ResultMatcher ​

如果你已经编写了自定义的匹配器用于 .andExpect 功能，可以通过 .matches 方法继续使用它们：

kotlin
@Test
fun `should reuse custom ResultMatcher with AssertJ style`() {
    // 使用新的流畅 API 构建请求，但复用现有的 ResultMatcher
    assertThat(mockMvc.get().uri("/hotels/{id}", 42))
        .matches(status().isOk()) 
        .matches(content().contentType(MediaType.APPLICATION_JSON))
}

3. 应用自定义的 ResultHandler ​

对于实现了 ResultHandler 契约的自定义处理器，可以使用 .apply 方法：

kotlin
class CustomResultHandler : ResultHandler {
    override fun handle(result: MvcResult) {
        // 自定义的结果处理逻辑
        println("Request processed: ${result.request.requestURI}")
        println("Response status: ${result.response.status}")
    }
}

@Test
fun `should apply custom ResultHandler`() {
    val customHandler = CustomResultHandler()
    
    assertThat(mockMvc.get().uri("/hotels/{id}", 42))
        .hasStatusOk()
        .apply(customHandler) 
}

实际业务场景示例 ​

让我们通过一个完整的酒店管理系统来看看这些集成方式在实际中的应用：

完整的测试示例代码
kotlin
@SpringBootTest
@AutoConfigureTestDatabase
@TestMethodOrder(OrderAnnotation::class)
class HotelControllerAdvancedTest {
    
    @Autowired
    private lateinit var mockMvc: MockMvcTester
    
    @Autowired
    private lateinit var hotelRepository: HotelRepository
    
    @BeforeEach
    fun setup() {
        // 准备测试数据
        hotelRepository.save(Hotel(
            id = 42L,
            name = "Grand Hotel",
            rooms = 100,
            rating = 4.5,
            location = "Downtown"
        ))
    }
    
    @Test
    @Order(1)
    fun `should get hotel with traditional RequestBuilder integration`() {
        // 场景1: 使用传统的 RequestBuilder，享受 AssertJ 断言
        assertThat(mockMvc.perform(
            get("/api/hotels/{id}", 42)
                .header("Accept-Language", "en-US")
                .param("includeRooms", "true")
        ))
            .hasStatusOk()
            .hasContentType(MediaType.APPLICATION_JSON)
            .bodyJson()
            .extractingPath("$.name").isEqualTo("Grand Hotel")
            .extractingPath("$.rooms").isEqualTo(100)
            .extractingPath("$.rating").isEqualTo(4.5)
    }
    
    @Test
    @Order(2)
    fun `should validate hotel creation with custom matchers`() {
        val newHotel = mapOf(
            "name" to "Luxury Resort",
            "rooms" to 200,
            "rating" to 5.0,
            "location" to "Beachfront"
        )
        
        // 场景2: 结合自定义 ResultMatcher
        assertThat(mockMvc.post().uri("/api/hotels")
            .contentType(MediaType.APPLICATION_JSON)
            .content(ObjectMapper().writeValueAsString(newHotel)))
            .hasStatus(HttpStatus.CREATED)
            .matches(header().string("Location", containsString("/api/hotels/"))) 
            .bodyJson()
            .extractingPath("$.id").isNotNull()
            .extractingPath("$.name").isEqualTo("Luxury Resort")
    }
    
    @Test
    @Order(3)
    fun `should handle hotel search with custom result handler`() {
        val searchHandler = object : ResultHandler {
            override fun handle(result: MvcResult) {
                val responseBody = result.response.contentAsString
                println("Search results: $responseBody") 
                // 可以在这里添加自定义的日志记录或监控逻辑
            }
        }
        
        // 场景3: 应用自定义 ResultHandler
        assertThat(mockMvc.get().uri("/api/hotels/search")
            .param("location", "Downtown")
            .param("minRating", "4.0"))
            .hasStatusOk()
            .apply(searchHandler) 
            .bodyJson()
            .isArray()
            .hasSizeGreaterThan(0)
    }
    
    @Test
    @Order(4)
    fun `should handle error scenarios gracefully`() {
        // 场景4: 错误处理测试
        assertThat(mockMvc.get().uri("/api/hotels/{id}", 999))
            .hasStatus(HttpStatus.NOT_FOUND)
            .bodyJson()
            .extractingPath("$.error").isEqualTo("Hotel not found")
            .extractingPath("$.timestamp").isNotNull()
    }
}

集成的核心优势 ✨ ​

1. 渐进式迁移 ​

2. 最佳实践建议 ​

迁移策略

  1. 第一阶段：在新测试中使用 MockMvcTester 的流畅 API
  2. 第二阶段：对现有测试使用 perform() 方法进行渐进式改造
  3. 第三阶段：逐步将复杂的断言逻辑迁移到 AssertJ 风格

3. 性能与可维护性 ​

注意事项

虽然集成提供了灵活性，但要注意：

  • 避免在同一个测试中混用过多不同的风格
  • 保持测试代码的一致性
  • 优先使用新的流畅 API，只在必要时才使用集成方法

总结 ​

MockMvc 与 AssertJ 的集成为我们提供了一个完美的过渡方案：

  1. 向后兼容 🔄：保护现有投资，无需重写所有测试
  2. 渐进升级 📈：可以逐步采用更优雅的测试风格
  3. 最佳体验 🎯：结合两个工具的优势，获得最佳的测试体验

IMPORTANT

记住，好的测试不仅要验证功能的正确性，更要具备良好的可读性和可维护性。MockMvc 与 AssertJ 的集成正是朝着这个目标迈出的重要一步！

通过这种集成方式，我们既能保持现有代码的稳定性，又能享受到现代测试框架带来的便利。这就是技术演进的魅力所在 —— 不是推倒重来，而是在继承中创新！ 🚀