听起来怎样，很酷吧。
　　这部分架构对于我们生态链前端的使用者来说基本是透明的。我们的项目只需要引入一个用于编写测试的 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以协调测试执行。