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