在本系列的第一部分中，我们看到了有效测试应满足的一些普遍适用的原则和约束。 在这一部分中，我们将仔细研究代码级单元测试以及组件或用例测试。

单元测试

单元测试验证单个单元（通常是类）的行为，而忽略或模拟该单元外部的所有问题。 单元测试应测试各个单元的业务逻辑，而不验证其进一步的集成或配置。

根据我的经验，大多数企业开发人员对单元测试的构建方式都有很好的了解。 您可以在我的咖啡测试项目中查看此示例，以了解想法。 大多数项目将JUnit与Mockito结合使用以模拟依赖关系，理想情况下使用AssertJ来有效定义可读的断言。 我一直认为，我们可以执行单元测试而无需特殊的扩展程序或运行程序，即仅使用纯JUnit运行它们。 原因很简单：执行时间； 我们应该能够在几毫秒内运行数百个测试。

单元测试通常执行速度非常快，并且易于执行，并且不会对测试套件的生命周期施加任何约束，因此可以轻松支持构建复杂的测试套件或特殊的开发工作流程。

但是，具有许多模拟被测类的依赖关系的单元测试的缺点是，它们将与实现紧密结合，尤其是类结构和方法，这使得重构代码变得困难。 换句话说，对于生产代码中的每个重构动作，测试代码也需要更改。 在最坏的情况下，这会导致开发人员进行较少的重构，这仅仅是因为它们变得太麻烦了，从而很快导致项目代码质量下降。 理想情况下，开发人员应该能够重构代码并四处移动，只要他们不改变应用程序的行为（从用户的角度来看）即可。 单元测试并不总是使重构生产代码变得容易。

根据项目经验，单元测试对于测试具有简洁逻辑或功能的高密度代码（例如特定算法的实现）非常有效，同时又不会与其他组件发生过多交互。 特定类中的代码密度越小或越复杂，循环复杂性越低，或者与其他组件的交互作用越高，则测试该类的单元测试效果就越差。 尤其是在具有少量专业业务逻辑并且与外部系统的集成程度相当的微服务中，可以说，对许多单元测试的需求减少了。 除了少数例外，这些系统的各个单元通常包含很少的专用逻辑。 选择在哪里花时间和精力进行权衡时，必须考虑到这一点。

用例测试

为了解决将测试与实现紧密耦合的问题，我们可以使用略有不同的方法来扩大测试范围。 在我的书中 ，我描述了组件测试的概念，因为缺少更好的术语，我们也可以将其称为用例测试。

用例测试是代码级别的集成测试，由于测试启动时间的原因，它们还没有使用嵌入式容器或反射扫描。 他们验证通常参与单个用例的一致组件的业务逻辑行为，从边界的业务方法一直到所有涉及的组件。 与外部系统（如数据库）的集成已被嘲笑。

在不使用更先进的技术自动建立组件连接的情况下构建此类方案听起来很费力。 但是，我们定义了可重用的测试组件或test double ，它们通过模拟，接线和测试配置来扩展组件，以最大程度地减少重构变更的整体工作量。 目标是制定单一职责，以将变更的影响限制在测试范围内的单个或几个类中。 以可重复使用的方式执行此操作会限制总体所需的工作量，并且在项目规模变大时会得到回报，因为我们每个组件只需支付一次管道费用，这很快就可以摊销。

为了获得更好的主意，假设我们正在测试订购咖啡的用例，其中包括两个类CoffeeShop和OrderProcessor 。

测试双重类CoffeeShopTestDouble和OrderProcessorTestDouble或*TD驻留在项目的测试范围中，而它们扩展了驻留在主要范围中的CoffeeShop和OrderProcessor组件。 测试双打可能会设置所需的模拟和连线逻辑，并可能使用与用例相关的模拟或验证方法来扩展类的公共接口。

下面显示了CoffeeShop组件的测试double类：

 public class CoffeeShopTestDouble extends CoffeeShop { public CoffeeShopTestDouble(OrderProcessorTestDouble orderProcessorTestDouble) { entityManager = mock(EntityManager. class ); orderProcessor = orderProcessorTestDouble; } public void verifyCreateOrder(Order order) { verify(entityManager).merge(order); } public void verifyProcessUnfinishedOrders() { verify(entityManager).createNamedQuery(Order.FIND_UNFINISHED, Order. class ); } public void answerForUnfinishedOrders(List<Order> orders) { // setup entity manager mock behavior }  } 

测试double类可以访问CoffeeShop基类的字段和构造函数以设置依赖项。 它使用其测试双重形式的其他组件（例如OrderProcessorTestDouble ）来能够调用用例中包含的其他模拟或验证方法。

测试双重类是可重用的组件，在每个项目范围内编写一次，并在多个用例测试中使用 ：

 class CoffeeShopTest { private CoffeeShopTestDouble coffeeShop; private OrderProcessorTestDouble orderProcessor; @BeforeEach void setUp() { orderProcessor = new OrderProcessorTestDouble(); coffeeShop = new CoffeeShopTestDouble(orderProcessor); } @Test void testCreateOrder() { Order order = new Order(); coffeeShop.createOrder(order); coffeeShop.verifyCreateOrder(order); } @Test void testProcessUnfinishedOrders() { List<Order> orders = Arrays.asList(...); coffeeShop.answerForUnfinishedOrders(orders); coffeeShop.processUnfinishedOrders(); coffeeShop.verifyProcessUnfinishedOrders(); orderProcessor.verifyProcessOrders(orders); }  } 

用例测试验证在入口点（这里为CoffeeShop上调用的单个业务用例的处理。 这些测试变得简短且易读，这是因为接线和模拟发生在单个测试双打中，并且它们还可以利用特定于用例的验证方法，例如verifyProcessOrders() 。

如您所见，测试双重扩展了生产范围类，用于设置模拟和验证行为的方法。 尽管这似乎是一些设置工作，但如果我们有多个用例可以在整个项目中重用组件，则成本将快速摊销。 我们的项目增长得越多，这种方法的好处就越大，尤其是当我们查看测试执行时间时。 我们所有的测试用例仍然使用JUnit运行，它可以立即执行数百个测试用例。

这是这种方法的主要优点：用例测试的运行速度与普通单元测试一样快，但由于仅需对单个或几个组件进行更改，因此可以方便地重构生产代码。 此外，使用针对我们领域的富有表现力的设置和验证方法来增强测试效率，从而使我们的测试代码更具可读性，便于使用，并避免了测试案例中的样板代码。

不包含任何高级测试上下文运行程序的代码级测试可以非常快速地执行，并且即使在非常复杂的项目中也不会为整体构建增加太多时间。 该系列的下一部分将显示代码级以及系统级集成测试。

翻译自: https://www.javacodegeeks.com/2019/09/efficient-enterprise-testing-unit-use-case.html