本系列文章的这一部分将介绍测试框架以及我在何时以及是否应用它们方面的想法和经验。

关于测试框架的思考

我对大多数测试框架不太满意的原因是，按照我的观点，它们大多增加了一些语法上的便利性和便利性，但本质上并不能解决拥有可维护的测试代码的问题。 换句话说，如果没有特定的测试技术就无法维护您的测试套件，那么仅通过引入另一个测试框架就很难改善它。

我声称，具有可读的测试代码的最大影响是通过精心设计测试代码的API和组件以及适当的抽象和委托来引入的。 这不依赖任何技术，而是在纯Java中完成的，在可以由JUnit执行的测试用例中。 为了验证特定步骤， AssertJ已经证明自己很不错。 我们可以定义特定于我们的业务逻辑的自定义断言，从而进一步提高代码的可读性。 如果测试用例需要模拟超出范围的类，则Mockito可以出色地完成这一工作。

我声称这些测试技术已经足够。 尤其是JUnit 5的出现，进一步增强了如何设置动态或参数化测试套件的功能。

尽管如此，仍有一些测试框架值得研究。 我完全不反对引入进一步的测试技术，因为它们无疑可以提高测试期间的可读性和效率。 但是，我声称关注测试代码质量至关重要，其他测试框架是可选的。

Spock是随Groovy API一起提供的测试框架，该框架相当知名，并已在项目中使用，目的是提高可读性和可维护性。 但是，我仍然会问这个技术能带来多少好处。 如果开发人员对其语法和方法感到满意，那很好； 但是，如果该项目完全是用Java编写的，那么与其提供的好处相比，可能需要更多的精力来管理和配置其他依赖项。 根据经验，我们花了很多时间在所有开发机器，CI / CD环境上配置Groovy及其版本，以及配置Maven构建。 由于我声称最大的投资回报来自测试代码质量，而不管所使用的技术如何，因此在复杂项目中使用Spock这样的框架的实际好处是很小的。

Testcontainers是一项在测试生命周期内设置和管理Docker容器的技术。 它使开发人员能够编排本地测试环境，其中可能包括被测应用程序，外部系统，模拟服务器或数据库。 这个开源项目在后台使用Docker的Java包装器，并将容器生命周期绑定到测试运行时。

尽管这种方法可以非常方便地在我们的测试用例中定义整个环境，并将管理减少到一个入口点，即执行Java测试类，但我通常主张不要将测试方案与测试环境生命周期相结合。 。 在每个测试案例中重新启动和重新部署本地测试环境会花费大量时间，并会减少即时反馈。 为了最大程度地减少整个周转时间，开发人员应该使本地环境长时间运行，并针对该环境运行幂等测试方案。 如果测试用例不影响生命周期，则更易于管理该设置。 将来，Testcontainer可以使声明的容器运行超出测试用例。 但是，在我看来，通过外壳程序脚本，Docker compose或Kubernetes在外部定义生命周期更加清晰，容易定义，而无需使用其他抽象。 过去，Docker Java包装器存在一些小问题，例如，当config JSON文件的格式更改时。 在我看来，诸如将工具包装到Java API中这样的抽象的优点通常不是很大，但是它们在配置和维护方面需要付出一定的努力，并且我们常常最终围绕它们的局限性建立解决方法。

因此，我仍然认为它是使用（bash）脚本或单独执行的类似方法来设置本地测试环境的最简单解决方案。 因此，明确定义了管理环境，设置和拆卸的责任； 测试方案仅使用并验证本地环境，并且可以立即运行。 直接使用shell脚本或技术（例如Docker Compose）可能并不那么花哨，但与您可以花多少时间（基于Java的）抽象相比，与管理依赖项，配置运行时和整合生命周期。 理想情况下，我们定义一个动作来在开发过程中设置本地环境。 我们的CI / CD管道可以使用类似的方法，也可以使用更复杂的设置，例如无论如何将我们的应用程序部署到Kubernetes集群。

使用普通技术运行测试的另一个好处是，通常可以轻松地将测试方案重新用于其他测试范围。 例如，当我们使用JAX-RS客户端而不是Restassured在测试场景中连接到我们的应用程序时，我们可以轻松地提取这些场景并重用代码来驱动性能或压力测试。 通过简单地交换一些较低级别的组件来定义对多个测试范围有效的测试方案时，情况也是如此。 测试框架修改和影响测试生命周期的次数越多，重用就变得越困难。 通常，我主张将测试生命周期，方案以及方案中各个步骤的实现的关注点分开。

Cucumber是一项可以轻松在多个范围内重用测试场景的技术。 我喜欢以一种非常抽象的方式定义方案并分别实现执行的方法。 最好用人类语言的Gherkin定义测试用例，最好是从纯粹的业务角度出发，而不会出现技术漏洞。 测试用例的实现可以互换。 这有点迫使在这些层之间切割。 在某些项目中，已证明在黄瓜测试中使用Gherkin格式可以与缺乏编程经验或没有编程经验的业务领域专家或人们进行交流。 相反，我还看到领域专家和QA工程师，如果测试场景方法简短且在测试内容中表现力十足，则他们非常擅长阅读Java代码。 我们对方法和内部API的命名越清楚，其他人就越能像prose一样阅读代码。 这项经验肯定了这样一种想法，即在精心制作的Java代码之上不一定需要其他技术。

通常，项目越复杂，测试技术对生产率，可读性和可维护性的影响就越小，并且它变得越重要，我们关心测试代码的质量，正确设计的抽象层以及关注点的分离。 如果开发人员希望在此基础上使用其他技术，那很好，但是我们需要注意一些折衷，例如，配置替代的JVM语言需要花费多少时间，它的依赖项和版本以及附加的权重。与在某些层上使用语法糖相比，我们的堆栈具有另一种技术。 可读性和可维护性来自于精心设计适当的抽象层，分离关注点和命名。 清楚地说明断言失败时出错的原因主要来自断言技术，例如AssertJ，它在提供开发人员由于某种原因而导致断言失败方面做得很好，因为开发人员首先做了断言。

如果您观看有关测试的演示中的教程或演示，这是我经常看不到的。 如果我们看简单的，类似Hello World的示例，那么适当的测试代码质量和结构的重要性可能不会马上就变得显而易见，而在小情况下，添加的语法糖似乎会带来巨大的收益。

本系列的下一部分和最后一部分将简要介绍其他端到端测试。

翻译自: https://www.javacodegeeks.com/2019/10/efficient-enterprise-testing-test-frameworks.html