JUnit 5系列之架構(gòu)體系介紹
現(xiàn)在，我們已經(jīng)知道了 如何配置 JUnit 5 環(huán)境 及 如何寫(xiě)一些測(cè)試，接下來(lái)就來(lái)看一點(diǎn)封面下的內(nèi)容吧。本篇我們將討論 JUnit 5 的架構(gòu)體系，以及它之成形如此的原因。
概述
本文章是這個(gè) JUnit 5 系列的一部分：
(如果不喜歡看文章，你可以戳這里看我的演講，或者看一下最近的 vJUG 講座，或者我在 DevoxxPL 上的 PPT。
本系列文章都基于 Junit 5發(fā)布的先行版 Milestone 2。它可能會(huì)有變化。如果有新的里程碑(milestone)版本發(fā)布，或者試用版正式發(fā)行時(shí)，我會(huì)再來(lái)更新這篇文章。
這里要介紹的多數(shù)知識(shí)你都可以在 JUnit 5 用戶指南 中找到(這個(gè)鏈接指向的是先行版 Milestone 2，想看的***版本文檔的話請(qǐng)戳這里)，并且指南還有更多的內(nèi)容等待你發(fā)掘。下面的所有代碼都可以在 我的 Github 上找到。
目錄
- JUnit 4
- JUnit 5
* 分離的關(guān)注點(diǎn)
* JUnit 5 的重新組織
* 架構(gòu)及體系
* API 生命周期
- Open test alliance
- 回顧總結(jié)
- 分享&關(guān)注
JUnit 4
除了 Hamcrest，JUnit 4沒(méi)有任何外部依賴(lài)，其所有的功能都被打包在一個(gè)構(gòu)件(artifact)中。這完全違反了單一職責(zé)原則，它被提供給開(kāi)發(fā)者、IDE、構(gòu)建工具、其他測(cè)試框架、其他擴(kuò)展等使用，不同的使用者，依賴(lài)的都是一個(gè)同樣的構(gòu)件。
而在這其中，只有開(kāi)發(fā)者能——或者說(shuō)曾經(jīng)能——以最干凈的方法來(lái)使用它。他們通常只需要 JUnit 的公共 API，不需要管其他的。非常好。
但生態(tài)圈中的其他成分則不是這樣使用 JUnit：測(cè)試框架、擴(kuò)展，特別是 IDE 和構(gòu)建工具的開(kāi)發(fā)者，他們需要深入到 JUnit 的深處，到它的細(xì)枝末節(jié)：非 public 的類(lèi)、內(nèi)部 API，甚至 private 字段。它們的正常工作極大地依賴(lài)于 JUnit 的實(shí)現(xiàn)細(xì)節(jié)。這使得 JUnit 維護(hù)團(tuán)隊(duì)不能輕易地修改框架的這些內(nèi)部實(shí)現(xiàn)，因此團(tuán)隊(duì)的開(kāi)發(fā)進(jìn)度受到了很大的影響。
當(dāng)然，這些工具的開(kāi)發(fā)者們也并非有意為之。為了實(shí)現(xiàn)那些我們十分喜愛(ài)的特性，他們不得不使用內(nèi)部的 API，因?yàn)?JUnit 4 并沒(méi)有提供相應(yīng)的 API：一個(gè)強(qiáng)大到足以滿足工具開(kāi)發(fā)者們需求的 API。
Junit Lambda 團(tuán)隊(duì)開(kāi)始著手于 JUnit 5 的開(kāi)發(fā)，希望能讓這一切變得明朗起來(lái)。
JUnit 5
分離的關(guān)注點(diǎn)
退一步想，我們不難辨識(shí)出，這里至少有兩個(gè)不同的關(guān)注點(diǎn)需要分離：
- 一個(gè)支持測(cè)試代碼撰寫(xiě)的 API
- 一個(gè)識(shí)別測(cè)試、運(yùn)行測(cè)試的機(jī)制
再仔細(xì)思考一下第二點(diǎn)，我們可能會(huì)問(wèn)，“哪些測(cè)試?”這個(gè)當(dāng)然是指 Junit 測(cè)試。“我知道，但具體是哪些版本的測(cè)試呢?”呃…“還有，具體是指什么類(lèi)型的測(cè)試?”好吧，你讓我給你……“只能跑那些老版本的 @Test 注解的測(cè)試么?有沒(méi)有其他新的方法來(lái)運(yùn)行測(cè)試呢?……”行行行，都給我閉嘴!聽(tīng)我講著。
為了進(jìn)一步將待識(shí)別測(cè)試的類(lèi)型 與 實(shí)際運(yùn)行它們 這兩個(gè)關(guān)注點(diǎn)解耦，上面的第二點(diǎn)需要細(xì)分：
- 一個(gè)支持測(cè)試代碼撰寫(xiě)的 API
- 一個(gè)識(shí)別測(cè)試、運(yùn)行測(cè)試的機(jī)制
* 一個(gè)識(shí)別、運(yùn)行特定類(lèi)型(比如，JUnit 5測(cè)試的機(jī)制)
* 另一套協(xié)調(diào)上述機(jī)制的機(jī)制
* 上兩者之間的 API
JUnit 5 的重新的組織
識(shí)別出這兩個(gè)關(guān)注點(diǎn)以后，“作為平臺(tái)的 JUnit ”(用于運(yùn)行我們的測(cè)試)和“作為工具的 JUnit ”(用于撰寫(xiě)我們的測(cè)試)這兩個(gè)概念的分離就清晰了。為了完成這個(gè)徹底的分離，JUnit 團(tuán)隊(duì)決定將 JUnit 5 分成三個(gè)子項(xiàng)目：
JUnit Jupiter
包含了我們用于撰寫(xiě)測(cè)試的 API(關(guān)注點(diǎn)1)，以及一個(gè)能理解測(cè)試代碼的引擎(關(guān)注點(diǎn)2.1)。
JUnit Platform
提供了一套統(tǒng)一的 API 以運(yùn)行測(cè)試，及基于 API 之上的一套工具(關(guān)注點(diǎn)2.2和2.3)。
JUnit Vintage
提供了一套引擎，用以在 JUnit 5 中運(yùn)行 JUnit 3 和 JUnit 4 的測(cè)試(關(guān)注點(diǎn)2.1)。
架構(gòu)與體系
JUnit 5 的架構(gòu)體系完全是遵循這個(gè)關(guān)注點(diǎn)分離思想的產(chǎn)物：
junit-jupiter-api(1)
開(kāi)發(fā)者用于撰寫(xiě)測(cè)試的 API，包含了我們?cè)贘Unit 5 的基礎(chǔ)知識(shí)一節(jié)中所提及的所有注解、斷言等。
junit-platgorm-engine(2.3)
包含了一套所有測(cè)試引擎都必須實(shí)現(xiàn)的 API。這樣，不同的測(cè)試引擎之間可以通過(guò)統(tǒng)一的接口被調(diào)用。引擎可以跑正常的 JUnit 測(cè)試，但也可以實(shí)現(xiàn)不同的引擎用以執(zhí)行其他框架寫(xiě)成的測(cè)試，如 TestNG、Spock、Cucumber 等。
junit-jupiter-engine(2.1)
junit-platform-engine API 的一個(gè)實(shí)現(xiàn)，專(zhuān)門(mén)用于執(zhí)行 JUnit 5 撰寫(xiě)的測(cè)試。
junit-vintage-engine(2.1)
junit-platform-engine API 的一個(gè)實(shí)現(xiàn)，專(zhuān)門(mén)用于執(zhí)行 JUnit 3 或 JUnit 4 撰寫(xiě)的測(cè)試。過(guò)去，JUnit 4 的構(gòu)件 junit-4.12 充當(dāng)了兩個(gè)角色：它既是開(kāi)發(fā)人員用于實(shí)現(xiàn)測(cè)試的 API，又包含了用以執(zhí)行測(cè)試的核心組件。這個(gè)引擎，可以認(rèn)為是低版本的 JUnit 3/4 與 JUnit 5 之間的一個(gè)適配器。
junit-platform-launcher(2.2)
這部分使用了一個(gè)服務(wù)加載器 ServiceLoader 來(lái)發(fā)現(xiàn)測(cè)試引擎，并協(xié)調(diào)不同實(shí)現(xiàn)之間的執(zhí)行。它提供了一個(gè) API 給 IDE 和構(gòu)建工具，使得它們能夠與測(cè)試執(zhí)行過(guò)程交互，比如，運(yùn)行單個(gè)的測(cè)試、搜集測(cè)試結(jié)果并展示等。
聽(tīng)起來(lái)怎樣，很酷吧。
這部分架構(gòu)對(duì)于我們生態(tài)鏈前端的使用者來(lái)說(shuō)基本是透明的。我們的項(xiàng)目只需要引入一個(gè)用于編寫(xiě)測(cè)試的 API 依賴(lài)，其余的組件讓工具去操心即可。
API 生命周期
現(xiàn)在來(lái)說(shuō)說(shuō)那些大家都在使用的內(nèi)部 API。JUnit 5 團(tuán)隊(duì)希望這個(gè)問(wèn)題也能得到解決，為此給 JUnit 的 API 設(shè)立了生命周期。這里，我將源碼中給出的部分解釋截取于此。
內(nèi)部 API(internal)
不允許被 JUnit 開(kāi)發(fā)者之外的任何人使用。這部分 API 可能被移除，并且不會(huì)事先通知。
已過(guò)時(shí)(Deprecated)
不應(yīng)該再被使用的 API，它們可能在下次小版本發(fā)布時(shí)被移除。
實(shí)驗(yàn)階段(Experimental)
為一些新的、實(shí)驗(yàn)階段的特性所使用的 API，這些新特性可能會(huì)或已經(jīng)被公開(kāi)使用并接受反饋中。
可以使用，但要謹(jǐn)慎。這些 API 未來(lái)可能被提升至 維護(hù)中 或 穩(wěn)定 級(jí)別，但也可能不帶提前通知就被移除。
維護(hù)中(Maintained)
使用該 API 的特性，至少在該大版本的下一個(gè)小版本發(fā)布時(shí)不會(huì)發(fā)生向后不兼容的改變。如果未來(lái)有移除維護(hù)中 API 的計(jì)劃，它會(huì)先被打回到 已過(guò)時(shí) 階段。
穩(wěn)定(Stable)
使用該 API 的特性，至少在下個(gè)大版本發(fā)布之前不會(huì)發(fā)生向后不兼容的改變。
JUnit 對(duì)外公開(kāi)的類(lèi)都帶有一個(gè) @API(usage) 注解，其中 usage 是上面幾個(gè)值中的其中一個(gè)。團(tuán)隊(duì)希望這能給 API 的調(diào)用方以充足的信息，即他們所使用的 API 處于什么生命周期中，同時(shí)，也希望給每個(gè)團(tuán)隊(duì)以自由，讓他們決定是否改變或移除過(guò)時(shí) API 。
Open Test Alliance
其實(shí)還有一件事。Junit 5 的體系結(jié)構(gòu)使得 IDE 和構(gòu)建工具能夠?qū)⑵渥鳛橹虚g層，以運(yùn)行所有類(lèi)型的測(cè)試框架(前提是該框架實(shí)現(xiàn)了其對(duì)應(yīng)的引擎)。這樣的話，工具本身就不需要去實(shí)現(xiàn)框架相關(guān)的測(cè)試支持，它們只需要使用一套統(tǒng)一的借口，即可實(shí)現(xiàn)測(cè)試發(fā)現(xiàn)、測(cè)試執(zhí)行和結(jié)果收集。
是嘛，真的可以嗎?
失敗的測(cè)試，通常使用異常來(lái)描述。但不同的測(cè)試框架和斷言庫(kù)之間并無(wú)一個(gè)統(tǒng)一的接口。相反，它們通常實(shí)現(xiàn)了各自不同的版本(常見(jiàn)的是繼承 AssertionError 或 RuntimeException )。這就使得不同框架間的互操作變得更加復(fù)雜，也使得工具之間無(wú)法簡(jiǎn)單使用一套統(tǒng)一的接口。
為了解決這個(gè)問(wèn)題，Junit Lambda 團(tuán)隊(duì)又分出來(lái)一個(gè)獨(dú)立的項(xiàng)目，The Open Test Alliance for the JVM。這是它們的提議：
基于 JUnit Lambda 團(tuán)隊(duì)近來(lái)與來(lái)自Eclipse、Gradle 及 Intellij 等 IDE 和構(gòu)建工具開(kāi)發(fā)者所展開(kāi)的討論，我們呼吁要建立這樣一個(gè)開(kāi)源項(xiàng)目：它用于提供一套基于 JVM的 測(cè)試庫(kù)與測(cè)試框架 間的最小公共接口集。
項(xiàng)目主要目標(biāo)是，為各測(cè)試框架(如 JUnit、TestNG、Spock 等)和三方斷言庫(kù)(Hamcrest、Assert 等)提供一個(gè)公共的異常集合。有了這個(gè)集合，IDE 和構(gòu)建工具就可以一個(gè)統(tǒng)一的接口對(duì)所有測(cè)試過(guò)程——如對(duì)失敗斷言、失敗假言判定的處理、對(duì)測(cè)試執(zhí)行過(guò)程的可視化、在 IDE 中生成測(cè)試結(jié)果報(bào)告等——進(jìn)行處理。
截止目前，該項(xiàng)目的呼吁似乎并未引起太多重視，或說(shuō)是基本未得到重視。如果你覺(jué)得這是個(gè)好的想法，你可以通過(guò)一些方式來(lái)支持，比如向你經(jīng)常使用的測(cè)試框架維護(hù)者發(fā)出聲音。
回顧總結(jié)
本篇我們介紹了 JUnit 5 的架構(gòu)設(shè)計(jì)，它將原有的 API 分成了兩部分：編寫(xiě)測(cè)試部分的 API 和 執(zhí)行測(cè)試的引擎。這個(gè)引擎進(jìn)一步地被切分成三個(gè)部分：一個(gè)解析測(cè)試代碼的 API、一個(gè)測(cè)試執(zhí)行器(launcher)，和一些支持不同測(cè)試框架的引擎實(shí)現(xiàn)。這樣開(kāi)發(fā)者只需要為項(xiàng)目引入 API 部分的依賴(lài)(用于編寫(xiě)測(cè)試)，而測(cè)試框架的開(kāi)發(fā)者們則只需要實(shí)現(xiàn)引擎部分的 API(其他工作已經(jīng)由 JUnit 處理了)，構(gòu)建工具方面也只需要實(shí)現(xiàn) launcher API以協(xié)調(diào)測(cè)試執(zhí)行。
