junit5和junit4

現在我們知道如何設置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

分離問題

退后一步，很容易找出至少兩個獨立的問題：

兩次寫入測試的API

發現和運行測試的機制

再仔細一點看第二點，我們可能會問“哪個測試？”。 好吧，當然是JUnit測試。 “是的，但是哪個版本？” 錯誤……“什么樣的測試？” 等待，讓我……“只是ust腳的@Test注釋過的舊方法？ 那lambdas呢？” 好，好，閉嘴！

為了使測試的具體變體與運行它們的關注脫鉤，這一點被分解：

兩次寫入測試的API

發現和運行測試的機制

發現和運行特定測試變體的機制（例如，JUnit 5）

協調特定機制的機制

他們之間的API

建筑

JUnit的體系結構是這種思路的結果：

junit5-api（1）

開發人員用來編寫測試的API。 包含我們討論JUnit 5基礎時看到的所有注釋，斷言等。

junit-enginge-api（2c）

所有測試引擎都必須實現API，因此可以以統一的方式訪問它們。 引擎可能會運行典型的JUnit測試，但實現可以運行用TestNG ， Spock ， Cucumber等編寫的測試。

junit5-engine（2a）

運行JUnit 5測試的junit-engine-api的實現。

junit4-engine（2a）

運行用JUnit 4編寫的測試的junit-engine-api的實現。這里，JUnit 4工件（例如junit-4.12 ）充當開發人員針對（1）實施測試的API，但還包含如何運行測試。 該引擎可以看作是版本5的JUnit 4的適配器。

junit-launcher（2b）

使用ServiceLoader發現測試引擎的實現并協調其執行。 它為IDE和構建工具提供API，以便它們可以與測試執行交互，例如通過啟動單個測試并顯示其結果。

有道理吧？

我們的一線開發人員將看不到大多數這種結構。 我們的項目只需要測試對我們正在使用的API的依賴即可； 其他所有內容都將隨我們的工具一起提供。

API生命周期

現在，關于每個人都在使用的內部API。 團隊也想解決這個問題，并為其API創建了生命周期。 就在這里，直接從源進行解釋：

內部

除JUnit本身外，不得用于任何其他代碼。 可能被刪除，恕不另行通知。

不推薦使用

如果不再使用，則可能會在下一個次要版本中消失。

實驗性

旨在提供我們希望獲得反饋的實驗性新功能。

保持

適用于至少在當前主版本的下一個次要版本中不會以向后不兼容的方式更改的功能。 如果計劃刪除，它將首先降級為“ 已棄用” 。

穩定

適用于在當前主要版本中不會以向后不兼容的方式更改的功能。

公開可見的類將使用@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和報告中可視化測試執行。

到目前為止，提到的項目的React還很差，即大多沒有。 如果您認為這是一個好主意，則可以通過與所選框架的維護者一起提出來支持它。

反射

我們已經看到了JUnit 5架構如何將用于編寫測試的API和用于運行測試的引擎劃分為單獨的部分，將引擎進一步拆分為API，使用它的啟動器，以及針對不同測試框架的實現。 這為用戶提供了精益的工件以進行測試（因為它們僅包含API），測試框架僅需為其API實現引擎（因為其余部分由JUnit處理），并且構建工具具有穩定的啟動器來協調測試執行。

本系列中有關JUnit 5的下一篇文章將討論其可擴展性。 敬請關注！

翻譯自: https://www.javacodegeeks.com/2016/04/junit-5-architecture.html

junit5和junit4

總結

以上是生活随笔為你收集整理的junit5和junit4_JUnit 5 –架构的全部內容，希望文章能夠幫你解決所遇到的問題。

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