2013年測試基于Web的Spring應用程序（第1部分）

LJCer和TDD / BDD的一位擁護者最近開始使用廣受歡迎的Spring堆棧開發應用程序，他就如何最好地在這種情況下實施測試驅動的方法向我提出了建議。 我開始回覆一封電子郵件作為回應，但后來我突然想到這也可能對其他人有用……所以在這里–我希望它能對您有所幫助

假設條件

本文的其余部分假定以下內容：

• 應用程序將使用Spring堆棧的以下組件在Java中實現：核心，MVC，數據，安全性等，但我們將不涉及Spring Integration或Batch（盡管推薦的測試框架和工具可能非常相似，但我發現測試這些組件的技術可能大不相同，因此必須等到另一篇博客文章為止）
• “最終用戶”將通過基于Web的UI和/或基于HTTP的API與開發的應用程序進行交互（通常，但不僅限于REST）
• 為了進行生產，將使用外部數據存儲在應用程序中保持長期狀態。 我們假設您也將要測試您的應用程序如何與此交互。
• 除了使用簡單的內存中的servlet容器（如Jetty）來部署整個打包的應用程序之外，我們將不涉及通過遠程或嵌入式容器進行的測試。 諸如Arquillian之類的框架提供了一些非常酷的功能，這些功能允許針對實際（嵌入式）容器（例如Tomcat，GlassFish和JBoss Application Server）進行單元測試。 這是通過提供機制來模擬生產類包裝（“ ShrinkWrapping ”）和在嵌入式容器內測試組件的任意子集（直至類級別）的方式來實現的，所有這些過程都可以通過您喜歡的測試框架進行，例如JUnit的。

一般建議

如果您是新的測試驅動開發人員，那么我推薦以下書籍：

• 有效的單元測試：Java開發人員指南 -這是對基于Java的單元測試中所有關鍵概念和技術的出色介紹（并且是最新的）。 本書不僅涵蓋了動機和方法，而且還介紹了如何編寫具有表現力和可維護性的“良好”測試，并針對每種用例選擇了最合適的技術。
• 使用JUnit和Mockito進行 實用單元測試和/或使用TestNG和Mockito進行實用單元測試 。 這些都是很棒的書，其中包含有關如何測試Java應用程序的大量實用示例，還討論了TDD的原因和方式。 這兩本書非常相似，主要區別在于用于驅動測試的框架。 我的建議是購買結合“有效單元測試”（主要側重于JUnit）的TestNG版本，因為很高興知道兩種最流行的基于Java的測試引擎的區別和優勢/劣勢。
• 由測試指導的不斷增長的面向對象軟件（貝克簽名） –這是經典的TDD書籍之一，它討論了測試驅動應用程序設計的所有高級概念和動機。 本書還詳細介紹了基于拍賣網站的整個應用程序的構建和演進過程，為如何使用規定的方法提供了一個很好的實踐示例。
• 有幾本關于單元測試JavaScript的書，盡管我沒有機會閱讀所有這些書，但我還是推薦Testable JavaScript。

測試核心

單元測試

目的 ：應用程序的核心對要解決的問題進行建模，通常包含特定于域的表示形式和相關的“業務”規則，這些規則主要由您負責編寫（即，在此處可以重用第三方代碼的機會是有點受限制）。

因此，很容易有人爭辯說，該代碼應該經過良好的測試-您在這里實現的組件不僅可能是唯一的，而且還希望在將它們連接到提供樣板功能的框架（例如，堅持不懈。 編寫良好的測試還可以在微觀級別上“記錄”您的代碼（及相關功能）。

工具 ：

• JUnit / TestNG –用于運行Java測試的事實上的框架。 我喜歡通過surefire插件將這些作為我的Maven構建過程的一部分運行
• Spock –基于Groovy的出色測試和規范框架。 如果您還沒有聽說過，請立即停止閱讀并訪問該網頁。 說真的 現在查看Spock基礎頁面 。 那有多棒？ 而且它在Spring中也能很好地發揮作用 ！
• Mockito –我最喜歡的模擬框架。 其他確實存在，但我發現Mockito在易用性，表達性和可維護性之間取得了很好的平衡
• PowerMock –當您遇到Mockito無法解決的困難情況時（例如，模擬依賴靜態方法的舊庫，模擬私有或最終方法，或模擬對象實例化），Mockito的強大擴展。 我的建議是，在開始接觸PowerMock時，始終對您的組件設計進行三重檢查–通常，使用PowerMock的愿望表明測試“有異味”，并可能表明您應該改進組件設計或您的方式。具有外部依賴性的代碼接口可以得到增強。 例如，除了模擬第三方庫的靜態構造方法之外，您是否可以不將此方法調用隱藏在自己的接口后面（遵循decoractor / adapter模式），這將簡化模擬？
• ConcurrentUnit –一個強大的實用程序框架，用于測試組件內并發的艱巨任務
• 輕松制作 -一個用于創建“測試數據”構建器的小框架（其概念來自前述的“ 不斷增長的面向對象的軟件，由測試指導”）
• junitparams –一個很好的框架，用于增強JUnits參數化測試（或如創建者所言–“不爛的參數化測試”）

做 ：

• 隔離測試中的類和組件。 單元測試應專注于測試小型工作單元 ，因此應具有最小的依賴關系（或應模擬依賴關系）
• 創建覆蓋整個代碼所有路徑的測試用例，而不僅僅是簡單的路徑
• 創建測試復制邊緣案例
• 利用參數化測試的功能來促進快速發現數據驅動的測試用例

不要 ：

• 編寫瑣碎的測試只是為了增加單元測試的覆蓋范圍
• 創建脆弱的測試，使您的代碼發生絲毫變化，即如果您使用超過10行代碼來設置模擬和期望，那么您可能做錯了
• 測試getter和setter，除非它們包含邏輯
• 直接測試與基礎操作系統（文件，網絡等），數據存儲或任何容器/服務器的任何交互。 在此測試級別上應該模擬這種交互

塞在一起

集成測試–持久層

目的 ：考慮對您的持久性或DAO層進行單元測試，但在這里您要模擬外部資源提供的行為，而不是模擬此功能。

工具 ：

• 上面提到的所有單元測試工具以及…
• 利用Spring的@ContextConfiguration來管理諸如EntityManager或MongoOperations之類的依賴關系的連接，以及利用AbstractTransactionalJUnit4SpringContextTests來管理具有明確定義的事務語義的測試的運行
• 您選擇的數據存儲的嵌入式（內存中）版本，例如
  • H2 –出色的嵌入式SQL數據存儲區，在99％的標準用例中，其行為類似于MySQL（盡管您的里程可能有所不同……）

做 ：

• 斷言實體可以按您期望的那樣持久。 我忘記了錯誤配置XToMany JPA批注的次數，這導致對子實體的級聯操作不正確。
• 旨在使測試執行時間保持在合理范圍內。
• 測試DAO /存儲庫界面上公開的所有公共方法
• 創建允許加載預先罐裝的測試數據的線束。 從Spring的AbstractTransactionalJUnit4SpringContextTests中考慮executeSqlScript（）
• 在每次測試結束時銷毀（或刪除）數據，以防止以前的測試數據影響結果。 如果您選擇的測試框架不能保證執行測試的順序，這一點尤其重要！

別

• 單元測試的覆蓋范圍過于重復，即大多數業務邏輯將調用持久層來加載數據，進行處理，然后再次調用持久層以保存結果。 此級別的測試只需要關注負載并保存
• 測試所有可能的數據排列
• 將太多的操作鏈接在一起–應該由服務集成測試或端到端測試覆蓋

即將第二部分...

我將盡快嘗試發布第2部分，它將涵蓋諸如服務級別集成測試，基于Web的測試和API測試之類的主題。 第3部分將介紹端到端（E2E）測試和BDD。

參考： The Tai-Dev Blog博客中的JCG合作伙伴 Daniel Bryant 在2013年測試了基于Web的Spring應用程序（第1部分） 。

翻譯自: https://www.javacodegeeks.com/2013/07/testing-web-based-spring-applications-in-2013-part-one.html

總結

以上是生活随笔為你收集整理的2013年测试基于Web的Spring应用程序（第1部分）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。