單元測試是軟件開發中必不可少的一環,可是在日常開發中每每由於項目週期緊,工做量大而被選擇忽略,這樣每每致使軟件問題層出不窮。線上出現的很多問題其實在有單元測試的狀況下就能夠及時發現和處理,所以培養本身在平常開發中寫單元測試的能力是頗有必要的。不管是對本身的編碼能力的提升,仍是項目質量的提高,都是大有好處,本文將介紹 Java 單元測試框架 JUnit 5 的基礎認識和使用來編寫單元測試,但願一樣對你有所幫助。java
本文所涉及全部代碼片斷均在下面倉庫中,感興趣的小夥伴歡迎參考學習:git
https://github.com/wrcj12138a...github
版本支持:編程
- JDK 8
- JUnit 5.5.2
- Lomok 1.18.8
要說什麼是 JUnit 5,首先就得聊下 Java 單元測試框架 JUnit,它與另外一個框架 TestNG 佔據了 Java領域裏單元測試框架的主要市場,其中 JUnit 有着較長的發展歷史和不斷演進的豐富功能,備受大多數 Java 開發者的青睞。segmentfault
而說到 JUnit 的歷史,JUnit 起源於 1997年,最第一版本是由兩位編程大師 Kent Beck 和 Erich Gamma 的一次飛機之旅上完成的,因爲當時 Java 測試過程當中缺少成熟的工具,兩人在飛機上就合做設計實現了 JUnit 雛形,旨在成爲更好用的 Java 測試框架。現在二十多年過去了,JUnit 通過各個版本迭代演進,已經發展到了 5.x 版本,爲 JDK 8以及更高的版本上提供更好的支持 (如支持 Lambda ) 和更豐富的測試形式 (如重複測試,參數化測試)。api
瞭解過 JUint 以後,再回頭來看下 JUnit 5,這個版本能夠說是 JUnit 單元測試框架的一次重大升級,首先須要 Java 8 以上的運行環境,雖然在舊版本 JDK 也能編譯運行,但要徹底使用 JUnit 5 功能, JDK 8 環境是必不可少的。數組
除此以外,JUnit 5 與之前版本的 JUnit 不一樣,拆分紅由三個不一樣子項目的幾個不一樣模塊組成。架構
JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage
基於上面的介紹,能夠參考下圖對 JUnit 5 的架構和模塊有所瞭解:框架
說完 JUnit 5 是什麼以後,咱們再來想一個問題:爲何須要一個 JUnit 5 呢?ide
自從有了相似 JUnit 之類的測試框架,Java 單元測試領域逐漸成熟,開發人員對單元測試框架也有了更高的要求:更多的測試方式,更少的其餘庫的依賴。所以,你們期待着一個更強大的測試框架誕生,JUnit 做爲Java測試領域的領頭羊,推出了 JUnit 5 這個版本,主要特性:
接下來,咱們看下 JUni 5 的一些常見用法,來幫助咱們快速掌握 JUnit 5 的使用。
首先,在 Maven 工程裏引入 JUnit 5 的依賴座標,需注意的是當前JDK 環境要在 Java 8 以上。
<dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <version>5.5.2</version> <scope>test</scope> </dependency>
引入JUnit 5,咱們能夠先快速編寫一個簡單的測試用例,從這個測試用例來認識初步下 JUnit 5:
@DisplayName("個人第一個測試用例") public class MyFirstTestCaseTest { @BeforeAll public static void init() { System.out.println("初始化數據"); } @AfterAll public static void cleanup() { System.out.println("清理數據"); } @BeforeEach public void tearup() { System.out.println("當前測試方法開始"); } @AfterEach public void tearDown() { System.out.println("當前測試方法結束"); } @DisplayName("個人第一個測試") @Test void testFirstTest() { System.out.println("個人第一個測試開始測試"); } @DisplayName("個人第二個測試") @Test void testSecondTest() { System.out.println("個人第二個測試開始測試"); } }
直接運行這個測試用例,能夠看到控制檯日誌以下:
能夠看到左邊一欄的結果裏顯示測試項名稱就是咱們在測試類和方法上使用 @DisplayName 設置的名稱,這個註解就是 JUnit 5 引入,用來定義一個測試類並指定用例在測試報告中的展現名稱,這個註解可使用在類上和方法上,在類上使用它就表示該類爲測試類,在方法上使用則表示該方法爲測試方法。
@Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Documented @API(status = STABLE, since = "5.0") public @interface DisplayName { String value(); }
再來看下示例代碼中使用到的一對註解 @BeforeAll 和 @AfterAll ,它們定義了整個測試類在開始前以及結束時的操做,只能修飾靜態方法,主要用於在測試過程當中所須要的全局數據和外部資源的初始化和清理。與它們不一樣,@BeforeEach 和 @AfterEach 所標註的方法會在每一個測試用例方法開始前和結束時執行,主要是負責該測試用例所須要的運行環境的準備和銷燬。
在測試過程當中除了這些基本的註解,還有更多豐富強大的註解,接下來就咱們一一學習下吧。
當咱們但願在運行測試類時,跳過某個測試方法,正常運行其餘測試用例時,咱們就能夠用上 @Disabled 註解,代表該測試方法處於不可用,執行測試類的測試方法時不會被 JUnit 執行。
下面看下使用 @Disbaled 以後的運行效果,在原來測試類中添加以下代碼:
@DisplayName("個人第三個測試") @Disabled @Test void testThirdTest() { System.out.println("個人第三個測試開始測試"); }
運行後看到控制檯日誌以下,用 @Disabled 標記的方法不會執行,只有單獨的方法信息打印:
@Disabled 也可使用在類上,用於標記類下全部的測試方法不被執行,通常使用對多個測試類組合測試的時候。
當咱們編寫的類和代碼逐漸增多,隨之而來的須要測試的對應測試類也會愈來愈多。爲了解決測試類數量爆炸的問題,JUnit 5提供了@Nested 註解,可以以靜態內部成員類的形式對測試用例類進行邏輯分組。 而且每一個靜態內部類均可以有本身的生命週期方法, 這些方法將按從外到內層次順序執行。 此外,嵌套的類也能夠用@DisplayName 標記,這樣咱們就可使用正確的測試名稱。下面看下簡單的用法:
@DisplayName("內嵌測試類") public class NestUnitTest { @BeforeEach void init() { System.out.println("測試方法執行前準備"); } @Nested @DisplayName("第一個內嵌測試類") class FirstNestTest { @Test void test() { System.out.println("第一個內嵌測試類執行測試"); } } @Nested @DisplayName("第二個內嵌測試類") class SecondNestTest { @Test void test() { System.out.println("第二個內嵌測試類執行測試"); } } }
運行全部測試用例後,在控制檯能看到以下結果:
在 JUnit 5 裏新增了對測試方法設置運行次數的支持,容許讓測試方法進行重複運行。當要運行一個測試方法 N次時,可使用 @RepeatedTest 標記它,以下面的代碼所示:
@DisplayName("重複測試") @RepeatedTest(value = 3) public void i_am_a_repeated_test() { System.out.println("執行測試"); }
運行後測試方法會執行3次,在 IDEA 的運行效果以下圖所示:
這是基本的用法,咱們還能夠對重複運行的測試方法名稱進行修改,利用 @RepeatedTest 提供的內置變量,以佔位符方式在其 name
屬性上使用,下面先看下使用方式和效果:
@DisplayName("自定義名稱重複測試") @RepeatedTest(value = 3, name = "{displayName} 第 {currentRepetition} 次") public void i_am_a_repeated_test_2() { System.out.println("執行測試"); }
@RepeatedTest 註解內用 currentRepetition
變量表示已經重複的次數,totalRepetitions
變量表示總共要重複的次數,displayName
變量表示測試方法顯示名稱,咱們直接就可使用這些內置的變量來從新定義測試方法重複運行時的名稱。
在斷言 API 設計上,JUnit 5 進行顯著地改進,而且充分利用 Java 8 的新特性,特別是 Lambda 表達式,最終提供了新的斷言類: org.junit.jupiter.api.Assertions 。許多斷言方法接受 Lambda 表達式參數,在斷言消息使用 Lambda 表達式的一個優勢就是它是延遲計算的,若是消息構造開銷很大,這樣作必定程度上能夠節省時間和資源。
如今還能夠將一個方法內的多個斷言進行分組,使用 assertAll 方法以下示例代碼:
@Test void testGroupAssertions() { int[] numbers = {0, 1, 2, 3, 4}; Assertions.assertAll("numbers", () -> Assertions.assertEquals(numbers[1], 1), () -> Assertions.assertEquals(numbers[3], 3), () -> Assertions.assertEquals(numbers[4], 4) ); }
若是分組斷言中任一個斷言的失敗,都會將以 MultipleFailuresError 錯誤進行拋出提示。
當咱們但願測試耗時方法的執行時間,並不想讓測試方法無限地等待時,就能夠對測試方法進行超時測試,JUnit 5 對此推出了斷言方法 assertTimeout
,提供了對超時的普遍支持。
假設咱們但願測試代碼在一秒內執行完畢,能夠寫以下測試用例:
@Test @DisplayName("超時方法測試") void test_should_complete_in_one_second() { Assertions.assertTimeoutPreemptively(Duration.of(1, ChronoUnit.SECONDS), () -> Thread.sleep(2000)); }
這個測試運行失敗,由於代碼執行將休眠兩秒鐘,而咱們指望測試用例在一秒鐘以內成功。可是若是咱們把休眠時間設置一秒鐘,測試仍然會出現偶爾失敗的狀況,這是由於測試方法執行過程當中除了目標代碼還有額外的代碼和指令執行會耗時,因此在超時限制上沒法作到對時間參數的徹底精確匹配。
咱們代碼中對於帶有異常的方法一般都是使用 try-catch 方式捕獲處理,針對測試這樣帶有異常拋出的代碼,而 JUnit 5 提供方法 Assertions#assertThrows(Class<T>, Executable)
來進行測試,第一個參數爲異常類型,第二個爲函數式接口參數,跟 Runnable 接口類似,不須要參數,也沒有返回,而且支持 Lambda表達式方式使用,具體使用方式可參考下方代碼:
@Test @DisplayName("測試捕獲的異常") void assertThrowsException() { String str = null; Assertions.assertThrows(IllegalArgumentException.class, () -> { Integer.valueOf(str); }); }
當Lambda表達式中代碼出現的異常會跟首個參數的異常類型進行比較,若是不屬於同一類異常,就會控制檯輸出以下相似的提示:org.opentest4j.AssertionFailedError: Unexpected exception type thrown ==> expected: <IllegalArgumentException> but was: <...Exception>
要使用 JUnit 5 進行參數化測試,除了 junit-jupiter-engine 基礎依賴以外,還須要另個模塊依賴:junit-jupiter-params,其主要就是提供了編寫參數化測試 API。一樣方式,把相同版本的對應依賴引入 Maven 工程中:
<dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-params</artifactId> <version>5.5.2</version> <scope>test</scope> </dependency>
@ValueSource 是 JUnit 5 提供的最簡單的數據參數源,支持 Java 的八大基本類型和字符串,Class,使用時賦值給註解上對應類型屬性,以數組方式傳遞,示例代碼以下:
public class ParameterizedUnitTest { @ParameterizedTest @ValueSource(ints = {2, 4, 8}) void testNumberShouldBeEven(int num) { Assertions.assertEquals(0, num % 2); } @ParameterizedTest @ValueSource(strings = {"Effective Java", "Code Complete", "Clean Code"}) void testPrintTitle(String title) { System.out.println(title); } }
@ParameterizedTest 做爲參數化測試的必要註解,替代了 @Test 註解。任何一個參數化測試方法都須要標記上該註解。
運行測試,結果以下圖所示,針對 @ValueSource 裏每一個參數都會運行目標方法,一旦哪一個參數運行測試失敗,就意味着該測試方法不經過。
經過 @CsvSource 能夠注入指定 CSV 格式 (comma-separated-values) 的一組數據,用每一個逗號分隔的值來匹配一個測試方法對應的參數,下面是使用示例:
@ParameterizedTest @CsvSource({"1,One", "2,Two", "3,Three"}) void testDataFromCsv(long id, String name) { System.out.printf("id: %d, name: %s", id, name); }
運行結果如圖所示,除了用逗號分隔參數外,@CsvSource 還支持自定義符號,只要修改它的 delimiter
便可,默認爲 ,
。
JUnit 還提供了讀取外部 CSV 格式文件數據的方式做爲數據源的實現,咱們只要用 @CsvFileSource 指定資源文件路徑便可,使用起來跟 @CsvSource 同樣簡單這裏就再也不重複演示了。
@CsvFileSource 指定的資源文件路徑時要以
/
開始,尋找當前測試資源目錄下文件。
除了上面提到的三種數據源方式外,JUnit 還提供瞭如下三種數據源:
provideArguments
方法能夠返回自定義類型的 Stream<Arguments> ,做爲測試方法所須要的數據使用。對上面三種數據源註解感興趣的同窗能夠參考示例工程的 ParameterizedUnitTest 類,這裏就不一一再介紹了。
到這裏,想必你對 JUnit 5 也有了基本的瞭解和掌握,都說單元測試是提高軟件質量,提高研發效率的必備環節,從會用 JUnit 5 寫單元測試開始,培養寫測試代碼的習慣,在不斷實踐中提高自身的開發效率,讓寫出來的代碼有更質量的保證。