junit5和junit4_JUnit 5 –架构

junit5和junit4

现在我们知道如何设置JUnit 5并使用它编写一些测试 ，下面让我们看一下。 在本文中，我们将讨论JUnit 5架构以及采用这种方式的原因。

总览

这篇文章是有关JUnit 5的系列文章的一部分：

• 建立
• 基本
• 建筑
• 条件
• 注射
• …

JUnit 4

忽略Hamcrest，JUnit 4没有依赖关系，并将所有功能捆绑在一个工件中。 这完全违反了单一责任原则，它表明：开发人员，IDE，构建工具，其他测试框架，扩展； 它们都依赖于相同的工件。

在这组开发人员中，行为最出色的是一次。 他们通常依赖于JUnit的公共API，仅此而已。

但是其他测试框架和扩展，尤其是IDE和构建工具则不同：它们深入到JUnit的内部。 非公共类，内部API甚至私有字段都不安全。 这样，它们最终取决于实现细节，这意味着JUnit维护者无法在需要时轻易更改它们，从而阻碍了进一步的开发。

当然，那些工具的开发人员并没有这样做。 为了实现我们非常重视的所有闪亮功能，他们必须使用内部功能，因为JUnit 4没有足够丰富的API来满足其要求。

JUnit Lambda团队着手使用JUnit 5使事情变得更好。

JUnit 5

分离问题

退后一步，很容易找出至少两个独立的问题：

1. 两次写入测试的API
2. 发现和运行测试的机制

再仔细一点看第二点，我们可能会问“哪个测试？”。 好吧，当然是JUnit测试。 “是的，但是哪个版本？” 错误……“什么样的测试？” 等待，让我……“只是ust脚的@Test注释过的旧方法？ 那lambdas呢？” 好，好，闭嘴！

为了使测试的具体变体与运行它们的关注脱钩，这一点被分解：

1. 两次写入测试的API
2. 发现和运行测试的机制
   1. 发现和运行特定测试变体的机制（例如，JUnit 5）
   2. 协调特定机制的机制
   3. 他们之间的API

建筑

JUnit的体系结构是这种思路的结果：

junit5-api（1）

开发人员用来编写测试的API。 包含我们讨论JUnit 5基础时看到的所有注释，断言等。

junit-enginge-api（2c）

所有测试引擎都必须实现API，因此可以以统一的方式访问它们。 引擎可能会运行典型的JUnit测试，但实现可以运行用TestNG ， Spock ， Cucumber等编写的测试。

junit5-engine（2a）

运行JUnit 5测试的junit-engine-api的实现。

junit4-engine（2a）

运行用JUnit 4编写的测试的junit-engine-api的实现。这里，JUnit 4工件（例如junit-4.12 ）充当开发人员针对（1）实施测试的API，但还包含如何运行测试。 该引擎可以看作是版本5的JUnit 4的适配器。

junit-launcher（2b）

使用ServiceLoader发现测试引擎的实现并协调其执行。 它为IDE和构建工具提供API，以便它们可以与测试执行交互，例如通过启动单个测试并显示其结果。

有道理吧？

我们的一线开发人员将看不到大多数这种结构。 我们的项目只需要测试对我们正在使用的API的依赖即可； 其他所有内容都将随我们的工具一起提供。

API生命周期

现在，关于每个人都在使用的内部API。 团队也想解决这个问题，并为其API创建了生命周期。 就在这里，直接从源进行解释：

内部

除JUnit本身外，不得用于任何其他代码。 可能被删除，恕不另行通知。

不推荐使用

如果不再使用，则可能会在下一个次要版本中消失。

实验性

旨在提供我们希望获得反馈的实验性新功能。

保持

适用于至少在当前主版本的下一个次要版本中不会以向后不兼容的方式更改的功能。 如果计划删除，它将首先降级为“ 已弃用” 。

稳定

适用于在当前主要版本中不会以向后不兼容的方式更改的功能。

公开可见的类将使用@API（usage）进行注释，其中用法是这些值之一。 按照计划，这样做可以使API调用者更好地了解他们正在进入的领域，并且团队可以自由地更改或删除不受支持的API。

开放测试联盟

不过，还有一件事。 JUnit 5体系结构使IDE和构建工具可以将其用作各种测试框架的基础（假设它们提供了相应的引擎）。 这样，工具就不必实施特定于框架的支持，而是可以统一发现，执行和评估测试。

还是可以？

测试失败通常用异常表示，但是不同的测试框架和断言库不共享公共集。 取而代之的是，大多数实现自己的变体（通常扩展AssertionError或RuntimeException），这使互操作性比必要的更为复杂，并防止工具进行统一处理。

为了解决此问题，JUnit Lambda团队拆分了一个单独的项目， 即JVM的开放测试联盟 。 这是他们的建议：

基于最近与IDE以及Eclipse，Gradle和IntelliJ的构建工具开发人员的讨论，JUnit Lambda团队正在研究一个开源项目的提案，以为在JVM上测试库提供最小的通用基础。

该项目的主要目标是使测试框架（如JUnit，TestNG，Spock等）和第三方断言库（如Hamcrest，AssertJ等）能够使用IDE和构建工具可以一致支持的一组通用异常。所有测试场景中的方式–例如，用于一致处理失败的断言和失败的假设以及在IDE和报告中可视化测试执行。

到目前为止，提到的项目的React还很差，即大多没有。 如果您认为这是一个好主意，则可以通过与所选框架的维护者一起提出来支持它。

反射

我们已经看到了JUnit 5架构如何将用于编写测试的API和用于运行测试的引擎划分为单独的部分，将引擎进一步拆分为API，使用它的启动器，以及针对不同测试框架的实现。 这为用户提供了精益的工件以进行测试（因为它们仅包含API），测试框架仅需为其API实现引擎（因为其余部分由JUnit处理），并且构建工具具有稳定的启动器来协调测试执行。

本系列中有关JUnit 5的下一篇文章将讨论其可扩展性。 敬请关注！

翻译自: https://www.javacodegeeks.com/2016/04/junit-5-architecture.html

junit5和junit4