測試框架 如何測試私有方法

本系列文章的這一部分將介紹測試框架以及我在何時以及是否應用它們方面的想法和經驗。

關于測試框架的想法

我對大多數測試框架不太滿意的原因是，按照我的觀點，它們大多增加了語法上的便利性和便利性，但是本質上并不能解決擁有可維護的測試代碼的問題。 換句話說，如果沒有特定的測試技術就無法維護您的測試套件，那么僅通過引入另一個測試框架就很難改善它。

我聲稱，具有可讀的測試代碼的最大影響是通過精心設計測試代碼的API和組件以及適當的抽象和委托來引入的。 這不依賴任何技術，而是在純Java中完成的，在可以由JUnit執行的測試用例中。 為了驗證特定步驟， AssertJ已經證明自己很不錯。 我們可以定義特定于我們的業務邏輯的自定義斷言，這進一步提高了代碼的可讀性。 如果測試用例需要模擬超出范圍的類，則Mockito可以出色地完成這一工作。

我聲稱這些測試技術已經足夠。 尤其是JUnit 5的出現，進一步增強了如何設置動態或參數化測試套件的功能。

盡管如此，仍有一些測試框架值得研究。 我完全不反對引入進一步的測試技術，因為它們無疑可以提高測試期間的可讀性和效率。 但是，我聲稱關注測試代碼質量至關重要，其他測試框架是可選的。

Spock是一個帶有Groovy API的測試框架，該框架相當知名，并已在項目中使用，目的是提高可讀性和可維護性。 但是，我仍然會問這個技術能帶來多少好處。 如果開發人員對其語法和方法感到滿意，那很好； 但是，如果該項目完全是用Java編寫的，那么與其提供的好處相比，可能需要更多的精力來管理和配置其他依賴項。 根據經驗，我們花了很多時間在所有開發機器，CI / CD環境上配置Groovy及其版本，以及配置Maven構建。 由于我聲稱最大的投資回報來自測試代碼質量，而與所使用的技術無關，因此在復雜項目中使用Spock這樣的框架的實際收益是很小的。

Testcontainers是一項在測試生命周期內設置和管理Docker容器的技術。 它使開發人員能夠編排本地測試環境，其中可能包括被測應用程序，外部系統，模擬服務器或數據庫。 這個開源項目在后臺使用Docker的Java包裝器，并將容器生命周期綁定到測試運行時。

盡管這種方法可以非常方便地在我們的測試用例中定義整個環境，并將管理減少到一個入口點，即執行Java測試類，但我通常主張不要將測試方案與測試環境生命周期相結合。 。 在每個測試案例中重新啟動和重新部署本地測試環境會花費太多時間，并會減少即時反饋。 為了最大程度地減少整個周轉時間，開發人員應該使本地環境長時間運行，并針對該環境運行冪等測試方案。 如果測試用例不影響生命周期，則更容易管理該設置。 將來，Testcontainers可以使聲明的容器運行超出測試用例。 但是，在我看來，通過外殼程序腳本，Docker compose或Kubernetes在外部定義生命周期，更清晰，更容易定義，而無需使用其他抽象。 過去，Docker Java包裝器存在一些小問題，例如，當config JSON文件的格式更改時。 在我看來，諸如將工具包裝到Java API中這樣的抽象的優點通常不是很大，但是它們在配置和維護方面需要付出一定的努力，而我們常常最終圍繞它們的局限性建立解決方法。

因此，我仍然認為它是使用（bash）腳本或單獨執行的類似方法來設置本地測試環境的最簡單解決方案。 因此，明確定義了管理環境，設置和拆卸的責任； 測試方案僅使用并驗證本地環境，并且可以立即運行。 直接使用shell腳本或技術（例如Docker Compose）可能并不那么花哨，但與您可以花多少時間（基于Java的）抽象相比，與管理依賴項，配置運行時和定義相比，定義起來實際上要快得多。整合生命周期。 理想情況下，我們定義一個動作來在開發過程中設置本地環境。 我們的CI / CD管道可以使用類似的方法，也可以使用更復雜的設置，例如無論如何將應用程序部署到Kubernetes集群。

使用普通技術運行測試的另一個好處是通常可以輕松地將測試方案重新用于其他測試范圍。 例如，當我們使用JAX-RS客戶端而不是Restassured在測試場景中連接到我們的應用程序時，我們可以輕松地提取這些場景并重用代碼來驅動性能或壓力測試。 當我們通過簡單地交換一些較低級別的組件來定義對多個測試范圍有效的測試方案時，情況也是如此。 測試框架修改和影響測試生命周期的次數越多，重用就變得越困難。 通常，我提倡將測試生命周期，方案以及方案中各個步驟的實現的關注點分開。

Cucumber是一項可以輕松在多個范圍內重用測試方案的技術。 我喜歡以一種非常抽象的方式定義方案并分別實現執行的方法。 最好用人類語言的Gherkin定義測試用例，最好是從純粹的業務角度出發，而不會出現技術漏洞； 測試用例的實現可以互換。 這有點迫使在這些層之間切割。 在某些項目中，事實證明，在Cucumber測試中使用Gherkin格式可以與缺乏編程經驗或沒有編程經驗的業務領域專家或人們進行交流。 相反，我還看到領域專家和QA工程師，如果測試場景方法簡短且在測試內容中表現力十足，則他們非常擅長閱讀Java代碼。 我們對方法和內部API的命名越清楚，其他人就越能像prose一樣閱讀代碼。 這項經驗證實了這樣一種想法，即在精心制作的Java代碼之上不一定需要其他技術。

通常，項目越復雜，測試技術對生產率，可讀性和可維護性的影響就越小，并且它越重要，我們就要關心測試代碼的質量，精心設計的抽象層以及關注點的分離。 如果開發人員希望在此基礎上使用其他技術，那很好，但是我們需要權衡利弊，例如，配置替代的JVM語言需要花費多少時間，它的依賴項和版本以及附加的權重。與在某些層上使用語法糖相比，我們的堆棧具有另一種技術。 可讀性和可維護性來自精心設計適當的抽象層，分離關注點和命名。 清楚地說明斷言失敗時出錯的原因主要來自斷言技術，例如AssertJ，它在提供開發者斷言由于什么原因而失敗方面做得很好，因為開發人員首先做了斷言。

如果您觀看有關測試的演示中的教程或演示，這是我經常看不到的。 如果我們看簡單的，類似于Hello World的示例，那么適當的測試代碼質量和結構的重要性可能不會馬上就變得不言而喻，而在小情況下，所添加的語法功能看起來似乎是巨大的收獲。

本系列的下一部分和最后一部分將簡要介紹其他端到端測試。

翻譯自: https://www.javacodegeeks.com/2019/10/efficient-enterprise-testing-test-frameworks.html

測試框架 如何測試私有方法

總結

以上是生活随笔為你收集整理的测试框架 如何测试私有方法_高效的企业测试–测试框架（5/6）的全部內容，希望文章能夠幫你解決所遇到的問題。

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