我看過多篇關于 Spring Boot 應用程式集成測驗的文章。鑒于應用程式遵循三層模式（Web 層 - 服務層 - 存盤庫層），我還沒有看到一篇文章將應用程式集成測驗到包含所有業務邏輯的服務層（省略 Web 層）。所有的集成測驗看起來都像控制器單元測驗——大多只是請求和回應有效載荷、引數等。
然而，我想要的是使用服務集成測驗來驗證業務邏輯。由于 web 層只負責從服務中獲取結果并與客戶端交換它們，我認為這更有意義。在運行服務之后，此類測驗還可以包含一些資料庫狀態驗證，以確保沒有分離的剩余物。
既然我從未見過這樣的測驗，那么實施一個是一個好習慣嗎？如果沒有，那為什么？
uj5u.com熱心網友回復：
這是基于意見的邊緣，但我仍然會分享我對此的看法。我通常遵循 Mike Cohn 的原始測驗金字塔，如下所示。
原因是單元測驗不僅更容易撰寫，而且速度更快，而且很可能比其他更細粒度的測驗覆寫更多。
然后我們遇到了服務或集成測驗，即您在問題中提到的那些。它們通常更難撰寫，因為您現在正在測驗整個應用程式，而不僅僅是單個類，并且運行時間更長。好處是您能夠測驗給定的場景，并且當您需要更改代碼中的某些內容時，它們很可能不需要像單元測驗那樣多的維護。
但是，這里是意見部分，我通常更喜歡將更多精力放在撰寫好的和廣泛的單元測驗上（但不會過多地關注測驗覆寫率，更多地關注我對該課程的期望），而不是完全成熟的集成測驗。我喜歡做的是利用Spring Slice 測驗，它在金字塔中將放置在單元測驗和服務測驗之間。它們允許您專注于特定類（例如控制器），但它們也允許您測驗與底層 Spring 框架或基礎設施的某些集成。這對我來說是兩全其美的。您仍然可以專注于單個類，但也可以測驗應用程式的一些相關組件。您可以使用@WebMvcTest或測驗您的 web 圖層@WebFluxTest（以便您可以測驗 JSON 反序列化和序列化、bean 驗證等...），或者您可以使用@DataJpaTest, @JdbcTestor專注于您的持久層@DataMongoTest（以便您可以測驗實際的持久性和資料檢索）。
總結一下，我通常會寫一堆單元測驗，然后是 web 層測驗來檢查我的控制器，還有一些針對真實資料庫的持久層測驗。
您可以在以下有趣的在線資源中閱讀更多內容：
- https://martinfowler.com/articles/practical-test-pyramid.html
- https://www.baeldung.com/spring-tests
uj5u.com熱心網友回復：
沒有一種真正正確的方法來測驗 Spring 應用程式。一般方法如您所述：
- 對嚴重依賴 Spring 的組件進行切片測驗 (
@DataJpaTest,@WebMvcTest) 等 - 域類和服務層的單元測驗
- 少量 e2e 測驗 (
@SpringBootTest) 以查看是否一切正常
另一方面，Spotify 工程師寫道他們幾乎不進行任何單元測驗，并且所有內容都包含在集成測驗中的集成測驗中。
沒有什么能阻止您使用@SpringBootTest所有底層組件來測驗您的服務層。您需要考慮以下事項：
- 準備測驗資料（或將系統置于某種狀態）比較困難，因為您需要將它們放入資料庫中
- 您需要自己清理資料庫，因為 (
@SpringBootTest) 不會回滾事務 - 測驗邊緣情況更難
- 你需要使用 Wiremock 之類的東西來模擬外部 HTTP 服務——這也比使用普通的 Mockito 更難
- 您需要注意在測驗期間創建的應用程式背景關系數量 - 首先它很慢，其次每個應用程式背景關系都將連接到資料庫，因此您將為每個背景關系創建 X 個連接，最終您可以達到資料庫服務器的限制。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/359943.html