大多数开发人员社区都知道单元测试是什么，即使他们不编写它们也是如此。还是有希望的。情况正在发生变化。越来越多托管在 GitHub 上的项目包含单元测试。
在 NetBeans、Maven 和 JUnit 等 Java 项目的标准设置中，生成您的第一个测试代码并不难。此外，这种方法用于测试驱动开发 (TDD) 并存在于其他技术中，例如行为驱动开发 (BDD)，也称为验收测试，这是我们将在本文中重点介绍的内容。
在电脑前手拿咖啡杯
单元测试和验收测试之间的区别
熟悉该主题的最简单方法是查看单元测试和验收测试之间的简单比较。在这种情况下，单元测试是非常低级的。他们执行一个函数并将输出与预期结果进行比较。有些人对此有不同的看法，但在我们的示例中，唯一负责单元测试的是开发人员
请记住，测试代码放在项目中，并始终在构建运行时执行。这提供了关于是否出现问题的快速反馈。只要测试不涉及太多方面，我们就能够快速定位问题并提供解决方案。这些测试的设计原则遵循 AAA 范式。定义前提条件 (Arrange)，执行不变量 (Act)，并检查后置条件 (Assume)。我们稍后会回到这种方法。
当我们使用 JaCoCo 等工具检查测试覆盖率并用测试用例覆盖超过 85% 的代码时，我们可以期待良好的质量。在增加测试覆盖率的过程中，我们更精确地指定了我们的测试用例，并且能够确定一些优化。这可以是移除或反转条件，因为在测试过程中我们发现，几乎不可能到达这些部分。当然，这个话题有点复杂，但这些细节可以在另一篇文章中讨论。
验收测试与单元测试的分类相同。它们属于回归测试系列。这意味着我们要观察我们对代码所做的更改是否对已经运行的功能没有影响。换句话说，我们要确保已经工作的任何东西都不会因为我们的改变的一些副作用而被破坏。我们选择的工具是JGiven。在我们看一些例子之前，首先，我们需要触及一些理论。
J深入了解
我们在 JGiven 中定义的测试用例称为场景。场景是四个类的集合：场景本身，显示为“给定（Arrange）”的Given ，显示为“when（Act） ”的Action ，显示为“then（Assume）”的Outcome 。
在大多数项目中，尤其是场景量大、执行耗时长的情况下，验收测试会组织在一个单独的项目中。通过在 CI 服务器上构建作业，您可以每天执行一次这些测试以获得快速反馈，并在出现问题时尽早做出反应。我们用来演示的代码示例包含GitHub 上一个项目中的所有内容，因为它只是一个小型库，分离只会过度设计项目。通常，负责验收测试的是测试中心，而不是开发人员。
示例项目 TP-CORE 由分层架构组织。对于我们的示例，我们选择了发送电子邮件的功能。编写电子邮件的基本功能在应用层实现，测试覆盖率高达90%。发送电子邮件的功能在服务层中定义。
在我们的架构中，我们决定服务层是我们定义验收测试的关注中心。在这里，我们想看看发送电子邮件的要求是否运行良好。用我们自己的单元测试来支持这一层效率并不高，因为在商业项目中，它只会产生成本而不会赢得收益。此外，还有单元测试意味着我们必须做双倍的工作，因为我们的 JGiven 测试已经证明并证明我们的功能运行良好。由于这些原因，为验收测试的测试场景生成测试覆盖率是没有意义的。
让我们从一个练习示例开始。首先，我们需要将我们的验收测试框架包含到我们的 Maven 构建中。如果您更喜欢 Gradle，您可以使用相同的 GAV 参数在构建脚本中定义依赖项。
正如您在清单 1 中看到的，JGiven 与 JUnit 一起工作得很好。还存在与 TestNG 的集成：您只需要替换artifactIdfor jgiven-testng。要启用 HTML 报告，您需要在构建生命周期中配置 Maven 插
我们在 TP-CORE 项目中的场景报告如上图所示。正如我们所看到的，输出非常具有描述性和人类可读性。这个结果将通过遵循我们的方法和类的一些命名约定来解释，这将在下面详细解释。首先，让我们讨论一下我们在测试场景中可以看到的内容。我们定义了五个先决条件：
SMPT 服务器的配置是可读的。
SMTP 服务器可用。
邮件有收件人。
邮件有附件。
邮件是完整的。
制作描述性场景
现在是深入研究发送电子邮件测试场景的实现细节的好时机。我们的测试对象是类MailClientService。对应的测试类是MailClientScenarioTest，定义在测试包中。场景类定义如清单 3 所示。
如我们所见，我们使用 JUnit5 执行测试框架。在 中 ScenarioTest，我们可以看到三个类：Given、Action和Outcome在特殊的命名约定中。也可以重用已经定义的类，但要小心这种做法。这可能会产生一些副作用。在我们现在实施测试方法之前，我们需要定义执行步骤。三个类的过程是等价的。