知識庫 / Spring RSS 訂閱

如果正確測試我們的服務，這種方法就足夠了：

class UsersControllerIntegrationTest : AbstractSpringIntegrationTest() {

    @Autowired
    lateinit var mvc: MockMvc
    
    @MockBean
    lateinit var userService: UserService

    @Test
    fun links() {
        mvc.perform(post("/users")
          .contentType(MediaType.APPLICATION_JSON)
          .content("""{ "name":"jose" }"""))
          .andExpect(status().isCreated)
        
        verify(userService).save("jose")
    }
}

interface UserService {
    fun save(name: String)
}

我們希望避免使用 @MockBean。因此，我們將持久化實體（假設服務確實這樣做）。

最簡單粗暴的方法是測試副作用：在 POST 之後，我的用户就在我的數據庫中，在我們的例子中，這會使用 JDBC。

然而，這違反了測試邊界：

@Test
fun links() {
    mvc.perform(post("/users")
      .contentType(MediaType.APPLICATION_JSON)
      .content("""{ "name":"jose" }"""))
      .andExpect(status().isCreated)

    assertThat(
      JdbcTestUtils.countRowsInTable(jdbcTemplate, "users"))
      .isOne()
}

在本例中，我們故意打破測試邊界，將我們的應用程序視為一個 HTTP 黑盒，發送用户請求，但隨後又使用實現細節進行斷言，即用户已被持久化到某個數據庫。

如果我們通過 HTTP 交互應用程序，是否也可以通過 HTTP 斷言結果？

@Test
fun links() {
    mvc.perform(post("/users")
      .contentType(MediaType.APPLICATION_JSON)
      .content("""{ "name":"jose" }"""))
      .andExpect(status().isCreated)

    mvc.perform(get("/users/jose"))
      .andExpect(status().isOk)
}

如果我們採用這種方法，將會有幾個優勢：

• 我們的測試將更快啓動（儘管可能需要稍微多一點時間執行，但應該能得到回報）
• 此外，我們的測試不瞭解與 HTTP 邊界無關的副作用，例如數據庫
• 最後，我們的測試清晰地表達了系統的意圖：如果使用 POST，您將能夠獲取 Users

當然，這可能並不總是可以實現的，原因有很多：

• 我們可能沒有“副作用”端點：這裏的一個選項是考慮創建“測試端點”
• 複雜度過高，無法覆蓋整個應用程序：這裏的一個選項是考慮切片（稍後我們會討論它們）

4.4. 仔細考慮 @DirtiesContext </h3

有時，我們可能需要在測試中修改 ApplicationContext。 為了應對這種情況，@DirtiesContext 提供了恰好所需的功能。

由於上述原因，@DirtiesContext 在執行時間方面是一個非常昂貴的資源，因此我們應該謹慎使用。

@DirtiesContext 的一些濫用包括應用緩存重置或內存數據庫重置。 在集成測試中處理這些場景有更好的方法，並在後續部分中我們會介紹一些。

4.5. 使用測試片（Test Slices）

測試片是 Spring Boot 從 1.4 版本開始引入的一個特性。其核心思想很簡單，Spring 會為您的應用程序的特定片（slice）創建一個簡化的應用上下文。

此外，框架會自動配置最基本的內容。

Spring Boot 自帶了足夠數量的測試片，我們也可以創建自己的測試片：

• @JsonTest:  註冊與 JSON 相關的組件
• @DataJpaTest:  註冊 JPA 實體，包括可用的 ORM
• @JdbcTest:  適用於原始 JDBC 測試，處理數據源和不帶 ORM 複雜性的內存數據庫
• @DataMongoTest:  嘗試提供內存 MongoDB 測試設置
• @WebMvcTest:  一個不包含應用程序其餘部分的小型 MVC 測試片
• … (您可以查看 源代碼 以查找所有測試片)

如果使用得當，這個特性可以幫助我們構建精簡的測試，而不會對性能產生過大的影響，尤其對於小型/中型應用程序而言。

然而，如果我們的應用程序不斷增長，它也會隨着創建每個（小型）應用上下文而堆積。

4.6. 使用類繼承

使用單個 <em >AbstractSpringIntegrationTest</em> 類作為所有集成測試的父類，是一種簡單、強大且務實的保持構建速度的方法。

如果我們提供一個可靠的設置，我們的團隊只需進行擴展，並知道“一切正常運行”。 這樣，我們就可以減少管理狀態或配置框架的精力，專注於解決手頭的問題。

我們可以在此設置所有測試要求：

• Spring 運行器 – 或更理想情況下，如果以後需要其他運行器，則使用規則
• profile – 理想情況下，我們的聚合 test profile
• 初始配置 – 設置應用程序的狀態

讓我們來看一個簡單的基類，它處理上述要點：

@SpringBootTest
@ActiveProfiles("test")
abstract class AbstractSpringIntegrationTest {

    @Rule
    @JvmField
    val springMethodRule = SpringMethodRule()

    companion object {
        @ClassRule
        @JvmField
        val SPRING_CLASS_RULE = SpringClassRule()
    }
}

4.7. 狀態管理

記住“unit”在單元測試中的來源至關重要，參考 這裏。 簡單來説，它意味着我們可以在任何時候運行單個測試（或子集），並獲得一致的結果。

因此，測試開始前狀態應該保持清潔且已知。

換句話説，無論測試是單獨執行還是與其他測試一起執行，測試結果都應該保持一致。

這個概念同樣適用於集成測試。 我們需要確保應用程序在開始新測試之前具有已知的（且可重複的）狀態。 隨着我們重用越來越多的組件（如應用程序上下文、數據庫、隊列、文件等）以加快速度，狀態污染的風險也會增加。

假設我們完全採用類繼承，現在我們有一箇中心位置來管理狀態。

讓我們增強我們的抽象類，以確保在運行測試之前應用程序處於已知的狀態。

在我們的示例中，我們假設存在多個倉庫（來自各種數據源），以及一個 Wiremock 服務器：

@SpringBootTest
@ActiveProfiles("test")
@AutoConfigureWireMock(port = 8666)
@AutoConfigureMockMvc
abstract class AbstractSpringIntegrationTest {

    //... spring rules are configured here, skipped for clarity

    @Autowired
    protected lateinit var wireMockServer: WireMockServer

    @Autowired
    lateinit var jdbcTemplate: JdbcTemplate

    @Autowired
    lateinit var repos: Set<MongoRepository<*, *>>

    @Autowired
    lateinit var cacheManager: CacheManager

    @Before
    fun resetState() {
        cleanAllDatabases()
        cleanAllCaches()
        resetWiremockStatus()
    }

    fun cleanAllDatabases() {
        JdbcTestUtils.deleteFromTables(jdbcTemplate, "table1", "table2")
        jdbcTemplate.update("ALTER TABLE table1 ALTER COLUMN id RESTART WITH 1")
        repos.forEach { it.deleteAll() }
    }

    fun cleanAllCaches() {
        cacheManager.cacheNames
          .map { cacheManager.getCache(it) }
          .filterNotNull()
          .forEach { it.clear() }
    }

    fun resetWiremockStatus() {
        wireMockServer.resetAll()
        // set default requests if any
    }
}

4.8. 將集成測試重構為單元測試

這是其中一個最重要的方面。我們經常會發現，某些集成測試實際上在測試應用程序的高層策略。

每當我們發現集成測試正在測試核心業務邏輯的多個用例時，就應該重新評估我們的方法，並將它們分解為單元測試。

一種可能的方法是：

1. 識別那些測試核心業務邏輯的多個用例的集成測試
2. 複製測試套件，並將副本重構為單元測試——在此階段，我們可能需要分解生產代碼以使其可測試
3. 確保所有測試通過
4. 保留一個足夠顯著的“happy path”樣本，該樣本在集成測試套件中，我們可能需要重構或合併和重塑幾個
5. 刪除剩餘的集成測試

Michael Feathers 在《Working Effectively with Legacy Code》一書中涵蓋了許多技術來實現這一目標以及更多技術。

5. 總結

本文介紹了與 Spring 相關的集成測試，重點在於集成測試。

首先，我們討論了集成測試的重要性以及它們在 Spring 應用中的相關性。

隨後，我們總結了一些可能對特定類型的 Web 應用集成測試有用的工具。

最後，我們回顧了一系列可能降低測試執行時間的問題，以及如何改進它們。