JUnit 5系列之?dāng)U展模型（Extension Model）介紹
概述
(如果不喜歡看文章，你可以戳這里看我的演講，或者看一下最近的 vJUG 講座，或者我在 DevoxxPL 上的 PPT。
本系列文章都基于 Junit 5發(fā)布的先行版 Milestone 2。它可能會(huì)有變化。如果有新的里程碑(milestone)版本發(fā)布，或者試用版正式發(fā)行時(shí)，我會(huì)再來(lái)更新這篇文章。
這里要介紹的多數(shù)知識(shí)你都可以在 JUnit 5 用戶(hù)指南 中找到(這個(gè)鏈接指向的是先行版 Milestone 2，想看的***版本文檔的話(huà)請(qǐng)戳這里)，并且指南還有更多的內(nèi)容等待你發(fā)掘。下面的所有代碼都可以在 我的 Github 上找到。
目錄
- JUnit 4 的擴(kuò)展模型
* Runners(運(yùn)行器)
* Rules(規(guī)則)
* 現(xiàn)狀
- JUnit 5 的擴(kuò)展模型
* 擴(kuò)展點(diǎn)
* 無(wú)狀態(tài)
* 應(yīng)用擴(kuò)展
* 自定義注解
- 例子
- 回顧總結(jié)
- 分享&關(guān)注
「譯者注：本篇的 Runner，統(tǒng)一譯為“運(yùn)行器”;Rule，統(tǒng)一譯為“規(guī)則”。雖不一定完全達(dá)義，但語(yǔ)義未損失太多。在每小節(jié)***次出現(xiàn)處會(huì)以中英標(biāo)注，其后全部使用中文。」
JUnit 4 的擴(kuò)展模型
我們先來(lái)看看 JUnit 4 中是如何實(shí)現(xiàn)擴(kuò)展的。在 JUnit 4 中實(shí)現(xiàn)擴(kuò)展主要是通過(guò)兩個(gè)，有時(shí)也互有重疊的擴(kuò)展機(jī)制：運(yùn)行器(Runners)和規(guī)則(Rules)。
運(yùn)行器(Runners)
測(cè)試運(yùn)行器負(fù)責(zé)管理諸多測(cè)試的生命周期，包括它們的實(shí)例化、setup/teardown 方法的調(diào)用、測(cè)試運(yùn)行、異常處理、發(fā)送消息等。在 JUnit 4 提供的運(yùn)行器實(shí)現(xiàn)中，它負(fù)責(zé)了這所有的事情。
在 JUnit 4 中，擴(kuò)展 JUnit 的唯一方法是：創(chuàng)建一個(gè)新的運(yùn)行器，然后使用它標(biāo)記你新的測(cè)試類(lèi)：@Runwith(MyRunner.class)。這樣 JUnit 就會(huì)識(shí)別并使用它來(lái)運(yùn)行測(cè)試，而不會(huì)使用其默認(rèn)的實(shí)現(xiàn)。
這個(gè)方式很重，對(duì)于小定制小擴(kuò)展來(lái)說(shuō)很不方便。同時(shí)它有個(gè)很苛刻的限制：一個(gè)測(cè)試類(lèi)只能用一個(gè)運(yùn)行器來(lái)跑，這意味著你不能組合不同的運(yùn)行器。也即是說(shuō)，你不能同時(shí)享受到兩個(gè)以上運(yùn)行器提供的特性，比如說(shuō)不能同時(shí)使用 Mockito 和 Spring 的運(yùn)行器，等。
規(guī)則(Rules)
為了克服這個(gè)限制，JUnit 4.7 中引入了規(guī)則的概念，它是指測(cè)試類(lèi)中特別的注解字段。 JUnit 4 會(huì)把測(cè)試方法(與一些其他的行為)包裝一層傳給規(guī)則。規(guī)則因此可以在測(cè)試代碼執(zhí)行前后插入，執(zhí)行一些代碼。很多時(shí)候在測(cè)試方法中也會(huì)直接調(diào)規(guī)則類(lèi)上的方法。
這里有一個(gè)例子，展示的是 temporary folder (臨時(shí)文件夾)規(guī)則：
- public static class HasTempFolder {
- @Rule
- public TemporaryFolder folder= new TemporaryFolder();
- @Test
- public void testUsingTempFolder() throws IOException {
- File createdFile= folder.newFile("myfile.txt");
- File createdFolder= folder.newFolder("subfolder");
- // ...
- }
- }
因?yàn)?@Rule 注解的存在，JUnit 會(huì)先把測(cè)試方法 testUsingTempFolder 包裝成一個(gè)可執(zhí)行代碼塊，傳給 folder 規(guī)則。這個(gè)規(guī)則的作用是執(zhí)行時(shí)， 由 folder 創(chuàng)建一個(gè)臨時(shí)目錄，執(zhí)行測(cè)試，測(cè)試完成后刪除臨時(shí)目錄。因此，在測(cè)試內(nèi)部可以放心地在臨時(shí)目錄下創(chuàng)建文件和文件夾。
當(dāng)然還有其他的規(guī)則，比如允許你在 Swing 的事件分發(fā)線程中執(zhí)行測(cè)試 的規(guī)則，負(fù)責(zé)連接和斷開(kāi)數(shù)據(jù)庫(kù)的規(guī)則，以及讓運(yùn)行過(guò)久的測(cè)試直接超時(shí)的規(guī)則等。
規(guī)則特性其實(shí)已經(jīng)是個(gè)很大的改進(jìn)了，不過(guò)仍有局限，它只能在測(cè)試運(yùn)行之前或之后定制操作。如果你想在此之外的時(shí)間點(diǎn)進(jìn)行擴(kuò)展，這個(gè)特性也無(wú)能為力了。
現(xiàn)狀
總而言之，在 JUnit 4 中存在兩種不同的擴(kuò)展機(jī)制，兩者均各有局限，并且功能還有重疊的部分。在 JUnit 4 下編寫(xiě)干凈的擴(kuò)展是很難的事。此外，即使你嘗試組合兩種不同的擴(kuò)展方式，通常也不會(huì)一帆風(fēng)順，有時(shí)它可能根本不按照開(kāi)發(fā)者期望的方式工作。
JUnit 5 的擴(kuò)展模型
Junit Lambda 項(xiàng)目成立伊始便有幾點(diǎn)核心準(zhǔn)則，其中一條便是“擴(kuò)展點(diǎn)優(yōu)于新特性”。這個(gè)準(zhǔn)則其實(shí)也就是新版本 JUnit 中最重要的擴(kuò)展機(jī)制了——并非唯一，但無(wú)疑是最重要之一。
擴(kuò)展點(diǎn)
JUnit 5 擴(kuò)展可以聲明其主要關(guān)注的是測(cè)試生命周期的哪部分。JUnit 5 引擎在處理測(cè)試時(shí)，它會(huì)依次檢查這些擴(kuò)展點(diǎn)，并調(diào)用每個(gè)已注冊(cè)的擴(kuò)展。大體來(lái)說(shuō)，這些擴(kuò)展點(diǎn)出現(xiàn)次序如下：
- 測(cè)試類(lèi)實(shí)例 后處理
- BeforeAll 回調(diào)
- 測(cè)試及容器執(zhí)行條件檢查
- BeforeEach 回調(diào)
- 參數(shù)解析
- 測(cè)試執(zhí)行前
- 測(cè)試執(zhí)行后
- 異常處理
- AfterEach 回調(diào)
- AfterAll 回調(diào)
(如果上面有你覺(jué)得不甚清晰或理解的點(diǎn)，請(qǐng)不用擔(dān)心，我們接下來(lái)會(huì)挑其中的一些來(lái)講解。)
每個(gè)擴(kuò)展點(diǎn)都對(duì)應(yīng)一個(gè)接口。接口方法會(huì)接受一些參數(shù)，一些擴(kuò)展點(diǎn)所處生命周期的上下文信息。比如，被測(cè)實(shí)例與方法、測(cè)試的名稱(chēng)、參數(shù)、注解等信息。
一個(gè)擴(kuò)展可以實(shí)現(xiàn)任意個(gè)以上的接口方法，引擎會(huì)在調(diào)用它們時(shí)傳入相應(yīng)的上下文信息作為參數(shù)。有了這些信息，擴(kuò)展就可以放心地實(shí)現(xiàn)所需的功能了。
無(wú)狀態(tài)
這里我們需要考慮一個(gè)重要的細(xì)節(jié)：引擎對(duì)擴(kuò)展實(shí)例的初始化時(shí)間、實(shí)例的生存時(shí)間未作出任何規(guī)約和保證，因此，擴(kuò)展必須是無(wú)狀態(tài)的。如果一個(gè)擴(kuò)展需要維持任何狀態(tài)信息，那么它必須使用 JUnit 提供的一個(gè)倉(cāng)庫(kù)(store)來(lái)進(jìn)行信息讀取和寫(xiě)入。
這樣做的原因有幾個(gè)：
- 擴(kuò)展的初始化時(shí)機(jī)和方式對(duì)引擎是未知的(每個(gè)測(cè)試實(shí)例化一次?每個(gè)類(lèi)實(shí)例化一次?還是每次運(yùn)行實(shí)例化一次?)。
- JUnit 不想額外維護(hù)和管理每個(gè)擴(kuò)展創(chuàng)建的實(shí)例。
- 如果擴(kuò)展之間想要進(jìn)行通信，那么無(wú)論如何 JUnit 都必須提供一個(gè)數(shù)據(jù)交互的機(jī)制。
應(yīng)用擴(kuò)展
創(chuàng)建完擴(kuò)展后，接下來(lái)需要做的就僅僅是告訴 JUnit 它的存在。這可以通過(guò)在需要使用該擴(kuò)展的測(cè)試類(lèi)或測(cè)試方法上添加一個(gè)@ExtendWith(MyExtension.class) 簡(jiǎn)單實(shí)現(xiàn)。
其實(shí)，還有另一種更簡(jiǎn)明的方式。不過(guò)要理解那種方式，我們必須先看一下 JUnit 的擴(kuò)展模型中還有哪些內(nèi)容。
自定義注解
JUnit 5 的 API 大部分是基于注解的，而且引擎在檢查注解時(shí)還做了些額外的工作：它不僅會(huì)查找字段、類(lèi)、參數(shù)上應(yīng)用的注解，還會(huì)注解上的注解。引擎會(huì)把找到的所有注解都應(yīng)用到被注解元素上。注解另一個(gè)注解可以通過(guò)所謂的元注解做到，酷的是 Junit 提供的所有注解都說(shuō)得上是元注解了。
它的意義在于，JUnit 5 中我們就能夠創(chuàng)建并組合不同的注解了，并且它們具備組合多個(gè)注解特性的能力：
- /**
- * We define a custom annotation that:
- * - stands in for '@Test' so that the method gets executed
- * - has the tag "integration" so we can filter by that,
- * e.g. when running tests from the command line
- */
- @Target({ElementType.TYPE, ElementType.METHOD})
- @Retention(RetentionPolicy.RUNTIME)
- @Test
- @Tag("integration")
- public @interface IntegrationTest { }
這個(gè)自定義的“集成測(cè)試”注解 @IntegrationTest 可以這樣使用：
- @IntegrationTest
- void runsWithCustomAnnotation() {
- // this gets executed
- // even though `@IntegrationTest` is not defined by JUnit
- }
進(jìn)一步我們可以為擴(kuò)展使用更簡(jiǎn)明的注解：
- @Target({ ElementType.TYPE, ElementType.METHOD, ElementType.ANNOTATION_TYPE })
- @Retention(RetentionPolicy.RUNTIME)
- @ExtendWith(ExternalDatabaseExtension.class)
- public @interface Database { }
現(xiàn)在我們可以直接使用 @Database 注解了，而不需要再聲明測(cè)試應(yīng)用了特定的擴(kuò)展@ExtendWith(ExternalDatabaseExtension.class)。并且由于我們把注解類(lèi)型 ElementType.ANNOTATION_TYPE 也添加到擴(kuò)展支持的目標(biāo)類(lèi)型中去了，因此該注解也可以被我們或他人進(jìn)一步的使用、組合。
例子
假設(shè)現(xiàn)在有個(gè)場(chǎng)景，我想量化一下測(cè)試運(yùn)行花費(fèi)的時(shí)間。首先，可以先創(chuàng)建一個(gè)我們想要的注解：
- @Target({ TYPE, METHOD, ANNOTATION_TYPE })
- @Retention(RetentionPolicy.RUNTIME)
- @ExtendWith(BenchmarkExtension.class)
- public @interface Benchmark { }
注解聲明其應(yīng)用了 BenchmarkExtension 擴(kuò)展，這是我們接下來(lái)要實(shí)現(xiàn)的。TODOLIST 如下：
- 計(jì)算所有測(cè)試類(lèi)的運(yùn)行時(shí)間，在所有測(cè)試執(zhí)行前保存其起始時(shí)間
- 計(jì)算每個(gè)測(cè)試方法的運(yùn)行時(shí)間，在每個(gè)測(cè)試方法執(zhí)行前保存其起始時(shí)間
- 在每個(gè)測(cè)試方法執(zhí)行完畢后，獲取其結(jié)束時(shí)間，計(jì)算并輸出該測(cè)試方法的運(yùn)行時(shí)間
- 在所有測(cè)試類(lèi)執(zhí)行完畢后，獲取其結(jié)束時(shí)間，計(jì)算并輸出所有測(cè)試的運(yùn)行時(shí)間
- 以上操作，僅對(duì)所有注解了 @BenchMark 的測(cè)試類(lèi)或測(cè)試方法生效
***一點(diǎn)需求可能不是一眼便能發(fā)現(xiàn)。如果一個(gè)方法并未注解 @Benchmark 注解，它有什么可能被我們的擴(kuò)展處理? 一個(gè)語(yǔ)法上的原因是，如果一個(gè)擴(kuò)展被應(yīng)用到了一個(gè)類(lèi)上，那么它默認(rèn)也會(huì)應(yīng)用到類(lèi)中的所有方法上。因此，如果我們的需求是計(jì)算整個(gè)測(cè)試類(lèi)的運(yùn)行時(shí)間，但不需具體到類(lèi)中每個(gè)單獨(dú)方法的運(yùn)行時(shí)間時(shí)，類(lèi)中的測(cè)試方法就必須被手動(dòng)排除。這點(diǎn)我們可以通過(guò)單獨(dú)檢查每個(gè)方法是否應(yīng)用了注解來(lái)做到。
有趣的是，需求的前四點(diǎn)與擴(kuò)展點(diǎn)中的其中四個(gè)是一一對(duì)應(yīng)的：BeforeAll、BeforeTestExecution、AfterTestExecution 與 AfterAll。因此我們要做的任務(wù)便是實(shí)現(xiàn)這四個(gè)對(duì)應(yīng)的接口。具體實(shí)現(xiàn)很簡(jiǎn)單，把上面說(shuō)的翻譯成代碼即是：
- public class BenchmarkExtension implements
- BeforeAllExtensionPoint, BeforeTestExecutionCallback,
- AfterTestExecutionCallback, AfterAllExtensionPoint {
- private static final Namespace NAMESPACE =
- Namespace.of("BenchmarkExtension");
- @Override
- public void beforeAll(ContainerExtensionContext context) {
- if (!shouldBeBenchmarked(context))
- return;
- writeCurrentTime(context, LaunchTimeKey.CLASS);
- }
- @Override
- public void beforeTestExecution(TestExtensionContext context) {
- if (!shouldBeBenchmarked(context))
- return;
- writeCurrentTime(context, LaunchTimeKey.TEST);
- }
- @Override
- public void afterTestExecution(TestExtensionContext context) {
- if (!shouldBeBenchmarked(context))
- return;
- long launchTime = loadLaunchTime(context, LaunchTimeKey.TEST);
- long runtime = currentTimeMillis() - launchTime;
- print("Test", context.getDisplayName(), runtime);
- }
- @Override
- public void afterAll(ContainerExtensionContext context) {
- if (!shouldBeBenchmarked(context))
- return;
- long launchTime = loadLaunchTime(context, LaunchTimeKey.CLASS);
- long runtime = currentTimeMillis() - launchTime;
- print("Test container", context.getDisplayName(), runtime);
- }
- private static boolean shouldBeBenchmarked(ExtensionContext context) {
- return context.getElement()
- .map(el -> el.isAnnotationPresent(Benchmark.class))
- .orElse(false);
- }
- private static void writeCurrentTime(
- ExtensionContext context, LaunchTimeKey key) {
- context.getStore(NAMESPACE).put(key, currentTimeMillis());
- }
- private static long loadLaunchTime(
- ExtensionContext context, LaunchTimeKey key) {
- return (Long) context.getStore(NAMESPACE).remove(key);
- }
- private static void print(
- String unit, String displayName, long runtime) {
- System.out.printf("%s '%s' took %d ms.%n", unit, displayName, runtime);
- }
- private enum LaunchTimeKey {
- CLASS, TEST
- }
- }
- 「譯者：啊這代碼讓人心曠神怡。」
上面代碼有幾個(gè)地方值得留意。首先是 shouldBeBenchmarked 方法，它使用了 JUnit 的 API 來(lái)獲取當(dāng)前元素是否(被元)注解了@Benchmark 注解;其次， writeCurrentTime / loadLaunchTime 方法中使用了 Junit 提供的 store 以寫(xiě)入和讀取運(yùn)行時(shí)間。
源代碼在 Github 上可以找到。
下篇博文我會(huì)探討條件執(zhí)行的測(cè)試以及參數(shù)注入部分的內(nèi)容，同時(shí)為你展示如何使用其對(duì)應(yīng)的擴(kuò)展點(diǎn)。如果你已經(jīng)迫不及待了，那么請(qǐng)先參考這篇博客，它展示了將應(yīng)用了兩個(gè)規(guī)則(條件性禁用測(cè)試 及 臨時(shí)目錄)的 Junit 4 測(cè)試改裝成 JUnit 5 測(cè)試的方法。
總結(jié)回顧
通過(guò)本文我們了解到，在創(chuàng)建整潔、強(qiáng)大及可組合的擴(kuò)展上，JUnit 4 提供的運(yùn)行器和規(guī)則特性不夠理想。為了超越這些限制，JUnit 5 引入了一個(gè)更通用的概念：擴(kuò)展點(diǎn)。它允許自定義的擴(kuò)展主動(dòng)聲明，它需要在一個(gè)測(cè)試的什么節(jié)點(diǎn)上去介入。同時(shí)，我們還看到如何使用元注解來(lái)輕松地自定義注解。
我希望聽(tīng)到你的想法和反饋。
