标签：
JUnit 5
分离的关注点
退一步想，我们不难辨识出，这里至少有两个不同的关注点需要分离：
一个支持测试代码撰写的 API
一个识别测试、运行测试的机制
再仔细思考一下第二点，我们可能会问，“哪些测试？”这个当然是指 Junit 测试。“我知道，但具体是哪些版本的测试呢？”呃…“还有，具体是指什么类型的测试？”好吧，你让我给你……“只能跑那些老版本的 @Test 注解的测试么？有没有其他新的方法来运行测试呢？……”行行行，都给我闭嘴！听我讲着。
为了进一步将待识别测试的类型 与 实际运行它们 这两个关注点解耦，上面的第二点需要细分：
一个支持测试代码撰写的 API
一个识别测试、运行测试的机制
一个识别、运行特定类型（比如，JUnit 5测试的机制）
另一套协调上述机制的机制
上两者之间的 API
JUnit 5 的重新的组织
识别出这两个关注点以后，“作为平台的 JUnit ”（用于运行我们的测试）和“作为工具的 JUnit ”（用于撰写我们的测试）这两个概念的分离就清晰了。为了完成这个彻底的分离，JUnit 团队（腾云科技ty300.com）决定将 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（基础教程qkxue.net）。这样，不同的测试引擎之间可以通过统一的接口被调用。引擎可以跑正常的 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 未来可能被提升至 维护中 或 稳定 级别，但也可能不带提前通知就被移除。
稿源：勤快学QKXue.NET
标签：
原文地址：http://www.cnblogs.com/qkxue/p/5883921.html
