前言
單元測試是軟件開發(fā)中必不可少的一環(huán),但是在平常開發(fā)中往往因為項目周期緊,工作量大而被選擇忽略,這樣往往導(dǎo)致軟件問題層出不窮。線上出現(xiàn)的不少問題其實在有單元測試的情況下就可以及時發(fā)現(xiàn)和處理,因此培養(yǎng)自己在日常開發(fā)中寫單元測試的能力是很有必要的。無論是對自己的編碼能力的提高,還是項目質(zhì)量的提升,都是大有好處,本文將介紹 Java 單元測試框架 JUnit 5 的基礎(chǔ)認(rèn)識和使用來編寫單元測試,希望同樣對你有所幫助。
本文所涉及所有代碼片段均在下面?zhèn)}庫中,感興趣的小伙伴歡迎參考學(xué)習(xí):
https://github.com/wrcj12138aaa/junit5-actions
版本支持:
- JDK 8
- JUnit 5.5.2
- Lomok 1.18.8
認(rèn)識 JUnit 5
要說什么是 JUnit 5,首先就得聊下 Java 單元測試框架 JUnit,它與另一個框架 TestNG 占據(jù)了 Java領(lǐng)域里單元測試框架的主要市場,其中 JUnit 有著較長的發(fā)展歷史和不斷演進(jìn)的豐富功能,備受大多數(shù) Java 開發(fā)者的青睞。
而說到 JUnit 的歷史,JUnit 起源于 1997年,最初版本是由兩位編程大師 Kent Beck 和 Erich Gamma 的一次飛機(jī)之旅上完成的,由于當(dāng)時 Java 測試過程中缺乏成熟的工具,兩人在飛機(jī)上就合作設(shè)計實現(xiàn)了 JUnit 雛形,旨在成為更好用的 Java 測試框架。如今二十多年過去了,JUnit 經(jīng)過各個版本迭代演進(jìn),已經(jīng)發(fā)展到了 5.x 版本,為 JDK 8以及更高的版本上提供更好的支持 (如支持 Lambda ) 和更豐富的測試形式 (如重復(fù)測試,參數(shù)化測試)。
了解過 JUint 之后,再回頭來看下 JUnit 5,這個版本可以說是 JUnit 單元測試框架的一次重大升級,首先需要 Java 8 以上的運(yùn)行環(huán)境,雖然在舊版本 JDK 也能編譯運(yùn)行,但要完全使用 JUnit 5 功能, JDK 8 環(huán)境是必不可少的。
除此之外,JUnit 5 與以前版本的 JUnit 不同,拆分成由三個不同子項目的幾個不同模塊組成。
JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage
JUnit Platform: 用于JVM上啟動測試框架的基礎(chǔ)服務(wù),提供命令行,IDE和構(gòu)建工具等方式執(zhí)行測試的支持。
JUnit Jupiter:包含 JUnit 5 新的編程模型和擴(kuò)展模型,主要就是用于編寫測試代碼和擴(kuò)展代碼。
JUnit Vintage:用于在JUnit 5 中兼容運(yùn)行 JUnit3.x 和 JUnit4.x 的測試用例。
基于上面的介紹,可以參考下圖對 JUnit 5 的架構(gòu)和模塊有所了解:

為什么需要 JUnit 5
說完 JUnit 5 是什么之后,我們再來想一個問題:為什么需要一個 JUnit 5 呢?
自從有了類似 JUnit 之類的測試框架,Java 單元測試領(lǐng)域逐漸成熟,開發(fā)人員對單元測試框架也有了更高的要求:更多的測試方式,更少的其他庫的依賴。因此,大家期待著一個更強(qiáng)大的測試框架誕生,JUnit 作為Java測試領(lǐng)域的領(lǐng)頭羊,推出了 JUnit 5 這個版本,主要特性:
提供全新的斷言和測試注解,支持測試類內(nèi)嵌
更豐富的測試方式:支持動態(tài)測試,重復(fù)測試,參數(shù)化測試等
實現(xiàn)了模塊化,讓測試執(zhí)行和測試發(fā)現(xiàn)等不同模塊解耦,減少依賴
提供對 Java 8 的支持,如 Lambda 表達(dá)式,Sream API等。
JUnit 5 常見用法介紹
接下來,我們看下 JUni 5 的一些常見用法,來幫助我們快速掌握 JUnit 5 的使用。
首先,在 Maven 工程里引入 JUnit 5 的依賴坐標(biāo),需注意的是當(dāng)前JDK 環(huán)境要在 Java 8 以上。
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>5.5.2</version>
<scope>test</scope>
</dependency>
第一個測試用例
引入JUnit 5,我們可以先快速編寫一個簡單的測試用例,從這個測試用例來認(rèn)識初步下 JUnit 5:
@DisplayName("我的第一個測試用例")
public class MyFirstTestCaseTest {
@BeforeAll
public static void init() {
System.out.println("初始化數(shù)據(jù)");
}
@AfterAll
public static void cleanup() {
System.out.println("清理數(shù)據(jù)");
}
@BeforeEach
public void tearup() {
System.out.println("當(dāng)前測試方法開始");
}
@AfterEach
public void tearDown() {
System.out.println("當(dāng)前測試方法結(jié)束");
}
@DisplayName("我的第一個測試")
@Test
void testFirstTest() {
System.out.println("我的第一個測試開始測試");
}
@DisplayName("我的第二個測試")
@Test
void testSecondTest() {
System.out.println("我的第二個測試開始測試");
}
}
直接運(yùn)行這個測試用例,可以看到控制臺日志如下:
可以看到左邊一欄的結(jié)果里顯示測試項名稱就是我們在測試類和方法上使用 @DisplayName 設(shè)置的名稱,這個注解就是 JUnit 5 引入,用來定義一個測試類并指定用例在測試報告中的展示名稱,這個注解可以使用在類上和方法上,在類上使用它就表示該類為測試類,在方法上使用則表示該方法為測試方法。
@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@API(status = STABLE, since = "5.0")
public @interface DisplayName {
String value();
}
再來看下示例代碼中使用到的一對注解 **@BeforeAll **和 @AfterAll ,它們定義了整個測試類在開始前以及結(jié)束時的操作,只能修飾靜態(tài)方法,主要用于在測試過程中所需要的全局?jǐn)?shù)據(jù)和外部資源的初始化和清理。與它們不同,@BeforeEach 和 @AfterEach 所標(biāo)注的方法會在每個測試用例方法開始前和結(jié)束時執(zhí)行,主要是負(fù)責(zé)該測試用例所需要的運(yùn)行環(huán)境的準(zhǔn)備和銷毀。
在測試過程中除了這些基本的注解,還有更多豐富強(qiáng)大的注解,接下來就我們一一學(xué)習(xí)下吧。
禁用執(zhí)行測試:@Disabled
當(dāng)我們希望在運(yùn)行測試類時,跳過某個測試方法,正常運(yùn)行其他測試用例時,我們就可以用上 @Disabled 注解,表明該測試方法處于不可用,執(zhí)行測試類的測試方法時不會被 JUnit 執(zhí)行。
下面看下使用 @Disbaled 之后的運(yùn)行效果,在原來測試類中添加如下代碼:
@DisplayName("我的第三個測試")
@Disabled
@Test
void testThirdTest() {
System.out.println("我的第三個測試開始測試");
}
運(yùn)行后看到控制臺日志如下,用 @Disabled 標(biāo)記的方法不會執(zhí)行,只有單獨的方法信息打?。?/p>

@Disabled 也可以使用在類上,用于標(biāo)記類下所有的測試方法不被執(zhí)行,一般使用對多個測試類組合測試的時候。
內(nèi)嵌測試類:@Nested
當(dāng)我們編寫的類和代碼逐漸增多,隨之而來的需要測試的對應(yīng)測試類也會越來越多。為了解決測試類數(shù)量爆炸的問題,JUnit 5提供了@Nested 注解,能夠以靜態(tài)內(nèi)部成員類的形式對測試用例類進(jìn)行邏輯分組。 并且每個靜態(tài)內(nèi)部類都可以有自己的生命周期方法, 這些方法將按從外到內(nèi)層次順序執(zhí)行。 此外,嵌套的類也可以用@DisplayName 標(biāo)記,這樣我們就可以使用正確的測試名稱。下面看下簡單的用法:
@DisplayName("內(nèi)嵌測試類")
public class NestUnitTest {
@BeforeEach
void init() {
System.out.println("測試方法執(zhí)行前準(zhǔn)備");
}
@Nested
@DisplayName("第一個內(nèi)嵌測試類")
class FirstNestTest {
@Test
void test() {
System.out.println("第一個內(nèi)嵌測試類執(zhí)行測試");
}
}
@Nested
@DisplayName("第二個內(nèi)嵌測試類")
class SecondNestTest {
@Test
void test() {
System.out.println("第二個內(nèi)嵌測試類執(zhí)行測試");
}
}
}
運(yùn)行所有測試用例后,在控制臺能看到如下結(jié)果:

重復(fù)性測試:@RepeatedTest
在 JUnit 5 里新增了對測試方法設(shè)置運(yùn)行次數(shù)的支持,允許讓測試方法進(jìn)行重復(fù)運(yùn)行。當(dāng)要運(yùn)行一個測試方法 N次時,可以使用 @RepeatedTest 標(biāo)記它,如下面的代碼所示:
@DisplayName("重復(fù)測試")
@RepeatedTest(value = 3)
public void i_am_a_repeated_test() {
System.out.println("執(zhí)行測試");
}
運(yùn)行后測試方法會執(zhí)行3次,在 IDEA 的運(yùn)行效果如下圖所示:

這是基本的用法,我們還可以對重復(fù)運(yùn)行的測試方法名稱進(jìn)行修改,利用 @RepeatedTest 提供的內(nèi)置變量,以占位符方式在其 name 屬性上使用,下面先看下使用方式和效果:
@DisplayName("自定義名稱重復(fù)測試")
@RepeatedTest(value = 3, name = "{displayName} 第 {currentRepetition} 次")
public void i_am_a_repeated_test_2() {
System.out.println("執(zhí)行測試");
}

@RepeatedTest 注解內(nèi)用 currentRepetition 變量表示已經(jīng)重復(fù)的次數(shù),totalRepetitions 變量表示總共要重復(fù)的次數(shù),displayName 變量表示測試方法顯示名稱,我們直接就可以使用這些內(nèi)置的變量來重新定義測試方法重復(fù)運(yùn)行時的名稱。
新的斷言
在斷言 API 設(shè)計上,JUnit 5 進(jìn)行顯著地改進(jìn),并且充分利用 Java 8 的新特性,特別是 Lambda 表達(dá)式,最終提供了新的斷言類: org.junit.jupiter.api.Assertions 。許多斷言方法接受 Lambda 表達(dá)式參數(shù),在斷言消息使用 Lambda 表達(dá)式的一個優(yōu)點就是它是延遲計算的,如果消息構(gòu)造開銷很大,這樣做一定程度上可以節(jié)省時間和資源。
現(xiàn)在還可以將一個方法內(nèi)的多個斷言進(jìn)行分組,使用 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 錯誤進(jìn)行拋出提示。
超時操作的測試:assertTimeoutPreemptively
當(dāng)我們希望測試耗時方法的執(zhí)行時間,并不想讓測試方法無限地等待時,就可以對測試方法進(jìn)行超時測試,JUnit 5 對此推出了斷言方法 assertTimeout,提供了對超時的廣泛支持。
假設(shè)我們希望測試代碼在一秒內(nèi)執(zhí)行完畢,可以寫如下測試用例:
@Test
@DisplayName("超時方法測試")
void test_should_complete_in_one_second() {
Assertions.assertTimeoutPreemptively(Duration.of(1, ChronoUnit.SECONDS), () -> Thread.sleep(2000));
}
這個測試運(yùn)行失敗,因為代碼執(zhí)行將休眠兩秒鐘,而我們期望測試用例在一秒鐘之內(nèi)成功。但是如果我們把休眠時間設(shè)置一秒鐘,測試仍然會出現(xiàn)偶爾失敗的情況,這是因為測試方法執(zhí)行過程中除了目標(biāo)代碼還有額外的代碼和指令執(zhí)行會耗時,所以在超時限制上無法做到對時間參數(shù)的完全精確匹配。
異常測試:assertThrows
我們代碼中對于帶有異常的方法通常都是使用 try-catch 方式捕獲處理,針對測試這樣帶有異常拋出的代碼,而 JUnit 5 提供方法 Assertions#assertThrows(Class<T>, Executable) 來進(jìn)行測試,第一個參數(shù)為異常類型,第二個為函數(shù)式接口參數(shù),跟 Runnable 接口相似,不需要參數(shù),也沒有返回,并且支持 Lambda表達(dá)式方式使用,具體使用方式可參考下方代碼:
@Test
@DisplayName("測試捕獲的異常")
void assertThrowsException() {
String str = null;
Assertions.assertThrows(IllegalArgumentException.class, () -> {
Integer.valueOf(str);
});
}
當(dāng)Lambda表達(dá)式中代碼出現(xiàn)的異常會跟首個參數(shù)的異常類型進(jìn)行比較,如果不屬于同一類異常,就會控制臺輸出如下類似的提示:org.opentest4j.AssertionFailedError: Unexpected exception type thrown ==> expected: <IllegalArgumentException> but was: <...Exception>
JUnit 5 參數(shù)化測試
要使用 JUnit 5 進(jìn)行參數(shù)化測試,除了 junit-jupiter-engine 基礎(chǔ)依賴之外,還需要另個模塊依賴:junit-jupiter-params,其主要就是提供了編寫參數(shù)化測試 API。同樣方式,把相同版本的對應(yīng)依賴引入 Maven 工程中:
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-params</artifactId>
<version>5.5.2</version>
<scope>test</scope>
</dependency>
基本數(shù)據(jù)源測試: @ValueSource
@ValueSource 是 JUnit 5 提供的最簡單的數(shù)據(jù)參數(shù)源,支持 Java 的八大基本類型和字符串,Class,使用時賦值給注解上對應(yīng)類型屬性,以數(shù)組方式傳遞,示例代碼如下:
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 作為參數(shù)化測試的必要注解,替代了 @Test 注解。任何一個參數(shù)化測試方法都需要標(biāo)記上該注解。
運(yùn)行測試,結(jié)果如下圖所示,針對 @ValueSource 里每個參數(shù)都會運(yùn)行目標(biāo)方法,一旦哪個參數(shù)運(yùn)行測試失敗,就意味著該測試方法不通過。

CSV 數(shù)據(jù)源測試:@CsvSource
通過 @CsvSource 可以注入指定 CSV 格式 (comma-separated-values) 的一組數(shù)據(jù),用每個逗號分隔的值來匹配一個測試方法對應(yīng)的參數(shù),下面是使用示例:
@ParameterizedTest
@CsvSource({"1,One", "2,Two", "3,Three"})
void testDataFromCsv(long id, String name) {
System.out.printf("id: %d, name: %s", id, name);
}
運(yùn)行結(jié)果如圖所示,除了用逗號分隔參數(shù)外,@CsvSource 還支持自定義符號,只要修改它的 delimiter 即可,默認(rèn)為 ,。

JUnit 還提供了讀取外部 CSV 格式文件數(shù)據(jù)的方式作為數(shù)據(jù)源的實現(xiàn),我們只要用 @CsvFileSource 指定資源文件路徑即可,使用起來跟 @CsvSource 一樣簡單這里就不再重復(fù)演示了。
@CsvFileSource 指定的資源文件路徑時要以
/開始,尋找當(dāng)前測試資源目錄下文件。
除了上面提到的三種數(shù)據(jù)源方式外,JUnit 還提供了以下三種數(shù)據(jù)源:
- @EnumSource:允許我們通過參數(shù)值,給指定 Enum 枚舉類型傳入,構(gòu)造出枚舉類型中特定的值。
- @MethodSource:指定一個返回的 Stream / Array / 可迭代對象 的方法作為數(shù)據(jù)源。 需要注意的是該方法必須是靜態(tài)的,并且不能接受任何參數(shù)。
-
@ArgumentSource:通過實現(xiàn) ArgumentsProvider 接口的參數(shù)類來作為數(shù)據(jù)源,重寫它的
provideArguments方法可以返回自定義類型的 Stream<Arguments> ,作為測試方法所需要的數(shù)據(jù)使用。
對上面三種數(shù)據(jù)源注解感興趣的同學(xué)可以參考示例工程的 ParameterizedUnitTest 類,這里就不一一再介紹了。
結(jié)語
到這里,想必你對 JUnit 5 也有了基本的了解和掌握,都說單元測試是提升軟件質(zhì)量,提升研發(fā)效率的必備環(huán)節(jié),從會用 JUnit 5 寫單元測試開始,培養(yǎng)寫測試代碼的習(xí)慣,在不斷實踐中提升自身的開發(fā)效率,讓寫出來的代碼有更質(zhì)量的保證。

推薦閱讀
- 一文掌握 Spring Boot Profiles
- 如何優(yōu)雅關(guān)閉 Spring Boot 應(yīng)用
- 需要接口管理的你了解一下?
- Java 之 Lombok 必知必會
- Java 微服務(wù)新生代之 Nacos