JUnit 5系列：架構(gòu)體系
作者：
Linesh林從羽 發(fā)布時間：
[ 2016/12/21 15:44:06 ] 推薦標簽：
單元測試 軟件測試
聽起來怎樣，很酷吧。
這部分架構(gòu)對于我們生態(tài)鏈前端的使用者來說基本是透明的。我們的項目只需要引入一個用于編寫測試的 API 依賴，其余的組件讓工具去操心即可。
API 生命周期
現(xiàn)在來說說那些大家都在使用的內(nèi)部 API。JUnit 5 團隊希望這個問題也能得到解決，為此給 JUnit 的 API 設立了生命周期。這里，我將 源碼 中給出的部分解釋截取于此。
內(nèi)部 API（internal）
不允許被 JUnit 開發(fā)者之外的任何人使用。這部分 API 可能被移除，并且不會事先通知。
已過時（Deprecated）
不應該再被使用的 API，它們可能在下次小版本發(fā)布時被移除。
實驗階段（Experimental）
為一些新的、實驗階段的特性所使用的 API，這些新特性可能會或已經(jīng)被公開使用并接受反饋中。
可以使用，但要謹慎。這些 API 未來可能被提升至 維護中 或 穩(wěn)定 級別，但也可能不帶提前通知被移除。
維護中（Maintained）
使用該 API 的特性，至少在該大版本的下一個小版本發(fā)布時不會發(fā)生向后不兼容的改變。如果未來有移除維護中 API 的計劃，它會先被打回到 已過時 階段。
穩(wěn)定（Stable）
使用該 API 的特性，至少在下個大版本發(fā)布之前不會發(fā)生向后不兼容的改變。
JUnit 對外公開的類都帶有一個 @API(usage) 注解，其中 usage 是上面幾個值中的其中一個。團隊希望這能給 API 的調(diào)用方以充足的信息，即他們所使用的 API 處于什么生命周期中，同時，也希望給每個團隊以自由，讓他們決定是否改變或移除過時 API 。
Open Test Alliance
其實還有一件事。Junit 5 的體系結(jié)構(gòu)使得 IDE 和構(gòu)建工具能夠?qū)⑵渥鳛橹虚g層，以運行所有類型的測試框架（前提是該框架實現(xiàn)了其對應的引擎）。這樣的話，工具本身不需要去實現(xiàn)框架相關(guān)的測試支持，它們只需要使用一套統(tǒng)一的借口，即可實現(xiàn)測試發(fā)現(xiàn)、測試執(zhí)行和結(jié)果收集。
是嘛，真的可以嗎？
失敗的測試，通常使用異常來描述。但不同的測試框架和斷言庫之間并無一個統(tǒng)一的接口。相反，它們通常實現(xiàn)了各自不同的版本（常見的是繼承 AssertionError 或 RuntimeException ）。這使得不同框架間的互操作變得更加復雜，也使得工具之間無法簡單使用一套統(tǒng)一的接口。
為了解決這個問題，Junit Lambda 團隊又分出來一個獨立的項目， The Open Test Alliance for the JVM 。這是它們的提議：
基于 JUnit Lambda 團隊近來與來自Eclipse、Gradle 及 Intellij 等 IDE 和構(gòu)建工具開發(fā)者所展開的討論，我們呼吁要建立這樣一個開源項目：它用于提供一套基于 JVM的 測試庫與測試框架 間的小公共接口集。
項目主要目標是，為各測試框架（如 JUnit、TestNG、Spock 等）和三方斷言庫（Hamcrest、Assert 等）提供一個公共的異常集合。有了這個集合，IDE 和構(gòu)建工具可以一個統(tǒng)一的接口對所有測試過程——如對失敗斷言、失敗假言判定的處理、對測試執(zhí)行過程的可視化、在 IDE 中生成測試結(jié)果報告等——進行處理。
截止目前，該項目的呼吁似乎并未引起太多重視，或說是基本未得到重視。如果你覺得這是個好的想法，你可以通過一些方式來支持，比如向你經(jīng)常使用的測試框架維護者發(fā)出聲音。
回顧總結(jié)
本篇我們介紹了 JUnit 5 的架構(gòu)設計，它將原有的 API 分成了兩部分：編寫測試部分的 API 和 執(zhí)行測試的引擎。這個引擎進一步地被切分成三個部分：一個解析測試代碼的 API、一個測試執(zhí)行器（launcher），和一些支持不同測試框架的引擎實現(xiàn)。這樣開發(fā)者只需要為項目引入 API 部分的依賴（用于編寫測試），而測試框架的開發(fā)者們則只需要實現(xiàn)引擎部分的 API（其他工作已經(jīng)由 JUnit 處理了），構(gòu)建工具方面也只需要實現(xiàn) launcher API以協(xié)調(diào)測試執(zhí)行。
