JUnit 5 –架构
現在我們知道如何設置JUnit 5并使用它編寫一些測試 ，下面讓我們看一下。 在本文中，我們將討論JUnit 5架構以及采用這種方式的原因。
總覽
這篇文章是有關JUnit 5的系列文章的一部分：
- 設定
- 基本
- 建筑
- 條件
- 注射
- …
JUnit 4
忽略Hamcrest，JUnit 4沒有依賴關系，并將所有功能捆綁在一個工件中。 這完全違反了單一責任原則，它表明：開發人員，IDE，構建工具，其他測試框架，擴展； 它們都依賴于相同的工件。
在這組開發人員中，有一次是表現最出色的開發人員。 他們通常依賴于JUnit的公共API，僅此而已。
但是其他測試框架和擴展，尤其是IDE和構建工具則不同：它們深入到JUnit的內部。 非公共類，內部API甚至私有字段都不安全。 這樣，它們最終取決于實現細節，這意味著JUnit維護者無法在需要時輕松更改它們，從而阻礙了進一步的開發。
當然，這些工具的開發人員并沒有這樣做。 為了實現我們非常重視的所有閃亮功能，他們必須使用內部功能，因為JUnit 4沒有足夠豐富的API來滿足其要求。
JUnit Lambda團隊著手使用JUnit 5使事情變得更好。
JUnit 5
分離問題
退后一步，很容易找出至少兩個獨立的問題：
再仔細一點看第二點，我們可能會問“哪個測試？”。 好吧，當然是JUnit測試。 “是的，但是哪個版本？” 錯誤……“什么樣的測試？” 等待，讓我……“只是ust腳的@Test注釋過的舊方法？ 那lambdas呢？” 好，好，閉嘴！
為了使測試的具體變體與運行它們的關注脫鉤，這一點被分解：
建筑
JUnit的體系結構是這種思路的結果：
junit5-api（1）有道理吧？
我們的一線開發人員將看不到大多數這種結構。 我們的項目只需要測試對我們正在使用的API的依賴即可； 我們的工具將附帶其他所有內容。
API生命周期
現在，關于每個人都在使用的內部API。 團隊也想解決這個問題，并為其API創建了生命周期。 就在這里，直接從源進行解釋：
內部公開可見的類將使用@API（usage）進行注釋，其中用法是這些值之一。 按照計劃，這樣做可以使API調用者更好地了解他們正在進入的領域，并且團隊可以自由地更改或刪除不受支持的API。
開放測試聯盟
不過，還有一件事。 JUnit 5體系結構使IDE和構建工具可以將其用作各種測試框架的基礎（假設它們提供了相應的引擎）。 這樣，工具就不必實施特定于框架的支持，而是可以統一地發現，執行和評估測試。
還是可以？
測試失敗通常用異常表示，但是不同的測試框架和斷言庫不共享相同的集合。 取而代之的是，大多數實現自己的變體（通常擴展AssertionError或RuntimeException），這使互操作性比必要的更為復雜，并防止工具進行統一處理。
為了解決這個問題，JUnit Lambda團隊拆分了一個單獨的項目， 即JVM的開放測試聯盟 。 這是他們的建議：
基于最近與IDE以及Eclipse，Gradle和IntelliJ的構建工具開發人員的討論，JUnit Lambda團隊正在研究一個開源項目的提案，以為在JVM上測試庫提供最小的通用基礎。
該項目的主要目標是使測試框架（如JUnit，TestNG，Spock等）和第三方斷言庫（如Hamcrest，AssertJ等）能夠使用IDE和構建工具可以一致支持的一組通用異常。跨所有測試方案的方式–例如，用于一致處理失敗的斷言和失敗的假設以及在IDE和報告中可視化測試執行。
到目前為止，所提到的項目的反應還不充分，即大多缺乏反應。 如果您認為這是一個好主意，則可以通過與所選框架的維護者一起提出來支持它。
反射
我們已經看到了JUnit 5架構如何將用于編寫測試的API和用于運行測試的引擎劃分為單獨的部分，將引擎進一步劃分為API，使用它的啟動器，以及針對不同測試框架的實現。 這為用戶提供了精益的工件以進行測試（因為它們僅包含API），測試框架僅需為其API實現引擎（因為其余部分由JUnit處理），并且構建工具具有穩定的啟動器來協調測試執行。
本系列中有關JUnit 5的下一篇文章將討論其可擴展性。 敬請關注！
翻譯自: https://www.javacodegeeks.com/2016/04/junit-5-architecture.html
總結
以上是生活随笔為你收集整理的JUnit 5 –架构的全部內容，希望文章能夠幫你解決所遇到的問題。
