2月初， JUnit 5（又名JUnit Lambda）團隊發布了一個alpha版本。 由于JUnit 4是我工具箱中使用最頻繁的項目之一，因此我認為值得一看下一個主要版本。

我試用了最新版本，并記下了我在這里發現值得注意的更改。

安裝JUnit 5

不用說，一個名為JUnit Lambda的項目需要Java 1.8或更高版本。 如果給出了，那么包括庫就很簡單了。 可從Sonatype的快照存儲庫（ https://oss.sonatype.org/content/repositories/snapshots/org/junit/ ）獲取當前Alpha發布通道的最新版本。

可以使用Maven和Gradle消耗工件。 如果您希望手動維護依賴性，那么還有一個可用的zip發行版 ，其中包含編譯和運行JUnit 5的所有內容。

在開發時，僅依賴org.junit:junit5-api模塊就足夠了。

請注意，在指定快照存儲庫時，應將其配置為從不緩存工件，以便始終使用最新版本。

從JUnit 4減輕負擔

據我所知，新版本是對庫的完全重寫，對舊版本沒有任何依賴性。 因此，您可以享受傳統的免費測試（至少一段時間；-）。

但是，當然有一條遷移路徑可以使兩個版本共存，并使您能夠在使用JUnit 5編寫新測試的同時維護現有的測試代碼庫。

相同但不同

但是，讓我們最后來看一下JUnit 5測試的樣子。 乍一看，變化不大。 一個簡單的測試課程…

class FirstTests {@Testvoid firstTest() {fail();} }

…與JUnit 4測試幾乎沒有區別。

但是，您發現細微的差別了嗎？ 是的，測試不再需要公開，但是如果您愿意，當然可以。

盡管注釋仍用于標識設置和拆除測試環境的方法，但其名稱已更改。 @BeforeClass/AfterClass現在是@BeforeAll/AfterAll而@Before/After現在是@BeforeEach/AfterEach 。

使用@Disabled批注仍然可以忽略測試。

@Test與@Test

如您所見，測試仍然使用@Test注釋標記。 但是要小心，如果您碰巧在類路徑上也有JUnit 4。 JUnit 5帶來了自己的@Test批注，因此請確保導入正確的org.junit.gen5.api.Test 。 否則，JUnit 5測試運行程序將找不到您的測試。

需要注意的另一件事是新的@Test注釋不提供其他服務。 如果你曾經使用timeout或expected不時，你將需要更換他們的JUnit 5。

使用JUnit 5運行測試

難怪還沒有IDE支持可以運行JUnit 5測試。 因此，我使用ConsoleRunner來執行實驗。 以這種方式運行測試還需要三個模塊：

• org.junit:junit5-engine
• org.junit:junit-launcher
• org.junit:junit-console

我選擇的IDE是Eclipse，為了從那里使用ConsoleRunner運行測試，我不得不手動擴展啟動配置的Classpath 。 僅在添加包含已編譯測試的test-classes輸出文件夾之后，它們才會被拾取。 但是，這種怪異也可能是由于我對Maven的了解不足，或者是由于Eclipse Maven集成中的特殊性。

JUnit 5團隊還提供了基本的插件來執行Maven和Gradle構建中的測試。 如果您想嘗試一下，請參閱“ 構建支持”一章。

斷言

乍一看，斷言沒有太大變化，只是斷言現在位于org.junit.gen5.api.Assertions類中。

但是仔細觀察發現， assertThat()已消失，并且不幸的是，它依賴于Hamcrest。 這些方法實際上復制了MatcherAssert提供的API，并將以前的JUnit版本綁定到Hamcrest庫。 這種依賴性有時會導致類解析沖突。 特別是與其他庫一起使用時，更糟糕的是，它們會自己包含Hamcrest的副本。

另一個更改是新的assertAll()方法，該方法用于對斷言進行分組。 例如

assertAll( "names", () -> {assertEquals( "John", person.getFirstName() );assertEquals( "Doe", person.getLastName() ); } );

將報告一個MultipleFailuresError其中包含組中所有失敗的斷言。

然后，測試執行者有責任以適當的方式顯示此故障。 但是，當前的ConsoleRunner實現尚未考慮分組故障，僅報告第一個故障：

Finished: testNames [junit5:com...GroupAssertionsTest#testNames()]=> Exception: names (1 failure)expected: <John> but was: <Mary>

我的第一個未經過濾的想法是，如果需要對斷言進行分組，則可能是將代碼分成多個測試的標志。 但是我還沒有真正使用分組的斷言，并且在某些地方也完全可以使用它們。

測試異常

測試異常已經統一。 要更換expected和ExpectedException現在有一個expectThrows斷言評估lambda表達式，并驗證它拋出指定類型的異常。

例如，

@Test void testException() {Foo foo = new Foo();Throwable exception = expectThrows( IllegalStateException.class, foo::bar );assertEquals( "some message", exception.getMessage() ); }

…如果調用foo::bar()沒有拋出IllegalStateException將失敗。 否則，將返回拋出的異常，并且可以對其進行進一步驗證。 如果拋出的異常assertThrows() ，則還有一個assertThrows()方法返回void。

再見亞軍，規則和ClassRule

JUnit 5不再知道運行器，規則或類規則。 這些部分競爭的概念已由單個一致的擴展模型代替。

可以通過@ExtendWith注釋測試類或測試方法來聲明性地使用擴展。 例如，希望使用模擬實例初始化某些字段的測試可以使用Mockito擴展，如下所示：

@ExtendWith(MockitoExtension.class) class MockedTest {@MockPerson person;// ...}

如果您對這個主題感興趣，請繼續關注有關擴展以及如何將現有規則遷移到我計劃編寫的自定義擴展的單獨文章。

測試方法參數

在JUnit 5中，現在允許方法具有參數。 這允許在方法級別注入依賴項。

為了提供參數，所謂的解析器是必需的，它是實現MethodParameterResolver的擴展。 與所有其他擴展一樣，要將解析器用于給定的方法或類，則需要使用@ExtendWith進行聲明。 還有兩個不需要明確聲明的內置解析器。 它們提供類型為TestInfo和TestReporter參數。

例如：

class MethodParametersTest {@Test// implicitly uses TestInfoParameterResolver to provide testInfovoid testWithBuiltIntParameterResolver( TestInfo testInfo ) {// ...}@Test@ExtendWith( CustomEnvironmentParameterResolver.class )// explicit resolver declared, could also be placed at class levelvoid testWithCustomParameterResolver( CustomEnvironment environment ) {// ...} }

如果在運行時找不到匹配的參數解析器，則引擎將通過相應的消息使測試失敗。

該文檔指出，有計劃提供其他擴展，其中還包括一個用于動態測試注冊的擴展。 有了這個擴展，就有可能進行參數化測試。 考慮到測試方法已經接受了參數，參數化測試似乎也可以在方法級別上使用。

向后兼容

為了縮小差距，直到IDE本地支持JUnit 5為止，有一個JUnit 4 Runner能夠執行為JUnit 5編寫的測試。使用@RunWith(JUnit5.class)批注來運行測試類和測試套件。

通過該運行器，可以并排運行JUnit 4和5測試類。 在單個測試中混合使用新舊概念當然是超出范圍的，例如，將@Rule與@ExtendWith等共存。

Mockito和AssertJ等測試實用程序將繼續使用新版本，而無需進行更改。 他們通過引發一個異常來與JUnit交互，即使在JUnit 5中，該異常仍然被認為是測試失敗：)

JVM開放測試聯盟

JUnit Lambda團隊還為JVM建立了開放測試聯盟 ，其目標是建立一個標準，以促進測試框架，斷言庫，模擬庫，構建工具和IDE之間的交互。

主要目標是提供一個庫，該庫定義測試框架（例如JUnit，TestNG，Spock等）要使用的一組通用異常，以及斷言庫。 構建工具和IDE也將受益，因為它們可以依賴相同的類型集，而與測試框架無關。

可以以org.opentest4j庫的形式獲得實現草案，您可以猜到它是JUnit 5使用的。

外表

我的印象是建立了新版本的基本概念。 諸如@Test，設置和拆卸注釋之類的東西，單個擴展模型的概念可能仍將保持其當前形狀。

但是許多細節似乎尚未解決，API可能會發生變化，我認為這在開發周期的現階段是可以理解的。 API的每個部分都標有@API注釋 ，以指示其穩定性。

如果這篇文章引起了您的興趣，并且您可能希望瀏覽文檔以獲取更多信息，那么還有很多值得探索的地方，例如：

• 用于過濾測試執行的標簽
• 嵌套測試以對測試進行分組并表達測試組之間的關系
• 可擴展的思路進行測試驗證規則 （如@Test和@BeforeEach不應該在同樣的方法進行）
• 在運行時動態注冊測試
• 注釋有助于并行運行測試

第一個里程碑計劃于2016年第一季度末發布。 此處提供了此發行版要解決的暫定項目列表。

翻譯自: https://www.javacodegeeks.com/2016/02/junit-5-first-look-next-generation-junit.html

總結

以上是生活随笔為你收集整理的JUnit 5 –下一代JUnit的初步了解的全部內容，希望文章能夠幫你解決所遇到的問題。

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