做网站用windows还是linux,徐州泉山建设局网站,濮阳市城乡一体化示范区主任,潍坊建设网站的公司电话如何设计高效测试用例在本系列的第一部分中#xff0c;我们看到了有效测试应满足的一些普遍适用的原则和约束。 在这一部分中#xff0c;我们将仔细研究代码级单元测试和组件或用例测试。 单元测试 单元测试验证单个单元#xff08;通常是类#xff09;的行为#xff0c… 如何设计高效测试用例 在本系列的第一部分中我们看到了有效测试应满足的一些普遍适用的原则和约束。 在这一部分中我们将仔细研究代码级单元测试和组件或用例测试。 单元测试 单元测试验证单个单元通常是类的行为而忽略或模拟该单元外部的所有问题。 单元测试应测试各个单元的业务逻辑而不验证其进一步的集成或配置。 根据我的经验大多数企业开发人员对单元测试的构建方式都有很好的了解。 您可以在我的咖啡测试项目中查看此示例以了解想法。 大多数项目将JUnit与Mockito结合使用以模拟依赖关系理想情况下使用AssertJ有效地定义可读的断言。 我一直认为我们可以执行单元测试而无需特殊的扩展程序或运行程序即仅使用纯JUnit运行它们。 原因很简单执行时间 我们应该能够在几毫秒内运行数百个测试。 单元测试通常执行速度非常快并且易于执行并且不会对测试套件的生命周期施加任何约束因此它们易于支持构建复杂的测试套件或特殊的开发工作流程。 但是具有许多模拟被测类的依赖关系的单元测试的缺点是它们将与实现紧密结合尤其是类结构和方法这使得重构代码变得困难。 换句话说对于生产代码中的每个重构动作测试代码也需要更改。 在最坏的情况下这会导致开发人员进行较少的重构这仅仅是因为它们变得太麻烦了从而Swift导致项目代码质量下降。 理想情况下开发人员应该能够重构代码并四处移动内容只要他们不改变应用程序的行为从用户的角度来看即可。 单元测试并不总是使重构生产代码变得容易。 根据项目的经验单元测试对于测试具有简洁逻辑或功能的高密度代码例如特定算法的实现非常有效同时又不会与其他组件发生过多交互。 特定类中的代码密度越小或越复杂循环复杂性越低或者与其他组件的交互性越高则测试该类的单元测试效果就越差。 尤其是在具有少量专业业务逻辑并且与外部系统具有大量集成的微服务中对许多单元测试的需求减少了。 除了少数例外这些系统的各个单元通常包含很少的专用逻辑。 在选择权衡时间和精力的地方时必须考虑到这一点。 用例测试 为了解决将测试与实现紧密耦合的问题我们可以使用略有不同的方法来扩大测试范围。 在我的书中 我描述了组件测试的概念因为缺少一个更好的术语我们也可以将其称为用例测试。 用例测试是代码级集成测试由于测试启动时间的原因该类测试尚未使用嵌入式容器或反射扫描。 他们验证通常参与单个用例的一致组件的业务逻辑行为从边界的业务方法一直到所有涉及的组件。 与外部系统如数据库的集成已被嘲笑。 在不使用自动连接组件的更先进技术的情况下构建此类方案听起来很费力。 但是我们定义了可重用的测试组件或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(ListOrder 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() { ListOrder orders Arrays.asList(...); coffeeShop.answerForUnfinishedOrders(orders); coffeeShop.processUnfinishedOrders(); coffeeShop.verifyProcessUnfinishedOrders(); orderProcessor.verifyProcessOrders(orders); } } 用例测试验证在入口点这里为CoffeeShop上调用的单个业务用例的处理。 这些测试变得简短且易于阅读因为接线和模拟发生在单个测试双打中并且它们还可以利用特定于用例的验证方法例如verifyProcessOrders() 。 如您所见测试双重扩展了生产范围类用于设置模拟和验证行为的方法。 尽管这似乎是一些设置工作但如果我们有多个用例可以在整个项目中重复使用这些组件则成本将Swift摊销。 我们的项目增长得越多这种方法的好处就越大尤其是当我们查看测试执行时间时。 我们所有的测试用例仍然使用JUnit运行它可以立即执行数百个测试用例。 这是此方法的主要优点用例测试的运行速度与普通单元测试一样快但由于仅需对单个或几个组件进行更改因此可以方便地重构生产代码。 此外使用针对我们领域的富有表现力的设置和验证方法来增强测试效率从而使我们的测试代码更具可读性更易于使用并避免了测试案例中的样板代码。 不包含任何高级测试上下文运行程序的代码级测试可以非常快速地执行并且即使在非常复杂的项目中也不会为整体构建增加太多时间。 该系列的下一部分将显示代码级以及系统级集成测试。 翻译自: https://www.javacodegeeks.com/2019/09/efficient-enterprise-testing-unit-use-case.html如何设计高效测试用例
