本系列的这一部分将展示如何通过代码级以及系统级集成测试来验证我们的应用程序。
（代码级）集成测试
集成测试一词有时在不同的上下文中使用不同。 根据Wikipedia的定义，我指的是在代码级别上验证多个组件之间相互作用的测试。 通常，集成测试利用嵌入式容器或其他模拟环境来测试应用程序的子集。 诸如Spring Tests，Arquillian，CDI-Unit之类的测试技术使编写测试变得容易，并且易于将各个类注入测试类以在测试执行期间进行直接交互。
下面显示了使用CDI-Unit运行器的集成测试的伪代码示例：
测试方案可以轻松注入和模拟依赖项，并可以在测试方法中访问它们。
由于嵌入式测试技术需要花一些时间才能启动，因此嵌入式集成测试通常对整个测试执行时间有最大的负面影响。 根据我的经验，许多项目会复制并粘贴现有的测试方案，并以每种测试类都会重新启动应用程序或其一部分的方式运行它们。 随着时间的推移，这会大大增加构建的周转时间，以至于开发人员将无法获得快速的反馈。
尽管这些类型的测试可以验证“管道”的正确性，但是API和注释是否被正确使用，它们并不是测试业务逻辑的最有效方法。 尤其是在微服务应用程序中，集成测试不能提供最终的信心，尤其是端点和持久性的集成是否会像生产环境中那样完全。 最终，在映射JSON对象，处理HTTP请求或将对象持久保存到数据存储的方式上，总会有微小的差异。
问题总是，我们的测试应该真正验证什么。 我们是否正在验证框架，框架的正确用法或整个应用程序的正确行为？
代码级集成测试很好地工作，可以快速反馈开发人员在连接框架时是否犯了一些粗心的错误。 在这种情况下，一些单个测试用例不能验证业务逻辑，而只是能够以冒烟测试的方式启动应用程序，就可以提高开发效率。
但是，如果我们的应用程序没有以过于复杂的方式利用我们的企业框架，例如使用自定义限定符，CDI扩展或自定义范围，那么对代码级集成测试的需求就会减少。 由于我们有使用系统测试来捕获相同类型错误的方法，还有许多其他方法，因此我通常不鼓励开发人员编写过多的代码级集成测试。 集成测试确实使在代码级别上连接多个组件变得容易，但是，可以使用不同的方法，例如用例测试，而这些方法并不会增加启动时间。
由于集成测试技术通常会启动或部署到容器中，因此它们通常会定义自己的生命周期，因此很难将其集成到更大的画面中。 如果开发人员想要制定优化的开发工作流程，则需要以一种模式运行应用程序，该模式可以在不同生命周期中热重新加载更改，然后针对正在运行的应用程序快速执行集成测试，而通过这些类型的集成测试很难做到这一点。 ，因为他们通常会启动自己的应用程序。 有一些技术可以改善这一点，例如Quarkus及其集成测试。 尽管如此，一种更简单，更灵活的方法是将测试方案与整个应用程序上下文的生命周期分开。
与（嵌入式）应用程序生命周期纠缠在一起的测试还使得很难在多个范围内重用测试方案，因为它们通常需要使用特定的运行程序或其他约束来执行。 在很多情况下，重用测试场景（定义测试逻辑部分的代码）在不同的范围内简化了增强测试套件的过程，例如用于用例测试，负载测试或系统测试。 如果这些案例对如何执行没有太多限制，例如与哪个测试运行程序一起使用，重用它们，即将它们复制到其他位置并交换使用的委托或组件的实现，则变得更加简单。 正如您将在以下内容中看到的，有很多有效的方法可以完全验证我们的应用程序，尤其是对于更复杂的项目。
系统测试
在微服务世界中，我们的应用程序越来越多地与其他资源（例如外部系统，数据库，队列或消息代理）集成在一起，并且通常包括不太复杂的业务逻辑。 话虽如此，从外部角度验证我们系统的行为至关重要，也就是说，以与生产中其他组件相同的方式与我们的应用程序进行交互。
系统测试通过使用常规接口（例如HTTP，gRPC，JMS或WebSockets）来验证已部署应用程序的行为。 它们是在环境中执行的，在该环境中，被测试应用程序的部署和配置与生产环境完全相同，通常会模拟或模拟外部系统。 测试方案可以与模拟的外部系统进行交互，以进一步控制方案并验证行为。 容器技术，模拟服务器和嵌入式数据库可以在这方面提供很多帮助。
通常，系统测试可以与实现分离，因此可以使用各种技术编写。 尽管使用与应用程序项目相同的技术通常是有意义的，因为开发人员已经熟悉它，例如，还将JUnit与HTTP客户端（例如JAX-RS）一起使用。
我们应该注意不要将系统测试与实际实现耦合在一起，也就是说，不要重复使用类定义或导入共享模块。 尽管这在项目中试图减少重复，但实际上增加了在应用程序界面更改时错过回归的可能性，有时是偶然的。 例如，如果生产代码和测试代码都更改了对象序列化为JSON的方式，则在重用类定义时（例如“垃圾回收，垃圾回收”），API合同中可能不需要的更改将不会被捕获。 ”）。 因此，通常建议将系统测试保存在单独的项目中，这些项目使用它们自己的，可能会简化的类定义，或者以其他方式强制测试类不会重复使用生产代码。 实现确实应验证通信是否按预期进行，例如检查预期的HTTP状态代码。 如果生产行为发生了不必要的变化，则系统测试项目及其行为不会被修改，并将检测到合同中的变化。
由于系统测试方案可能很快变得相当复杂，因此我们需要关注可维护性和测试代码质量。 我们将在稍后对此进行仔细研究，但是一般而言，建议构造特殊的委托以控制和与模拟的外部系统进行通信，以及创建测试数据。
对于更复杂的设置而言，至关重要的是定义幂等系统测试，以验证特定行为，而与当前状态无关。 我们应避免创建仅适用于全新的空系统或需要按特定顺序执行的测试方案。 实际的业务用例通常也在运行时间更长的系统上执行，并同时执行。 如果我们在系统测试中达到相同的隔离级别，则可以避免测试与特定的前提条件或执行顺序纠缠在一起，并且可以并行运行它们，也可以针对可以持续运行超过一次试运行。 这是建立有效的本地工作流以及潜在地出于不同目的重用测试方案定义的前提。
为了使环境保持相似，问题在于生产的外观如何以及在本地开发或持续交付管道中如何使生产尽可能接近。 通常，容器的出现使实现该目标变得更加容易。 如果我们的应用程序在容器中运行，我们可以通过多种方式在本地执行它们，或者通过外壳脚本，Docker Compose，测试容器启动它们，我们将在稍后介绍它们，或者甚至运行成熟的Kubernetes或OpenShift簇。 在持续交付管道中，我们理想地以与生产相同的方式部署到环境并对其进行测试，即使用相同技术和配置的集群或环境，例如单独的Kubernetes集群或命名空间。
根据系统的复杂性和本地开发工作流程，我们可以在系统测试执行中或通过单独的工具从外部管理已部署应用程序的生命周期。 根据经验，从外部管理环境（即通过单独的机制启动环境并对其进行幂等测试），可以更快地执行，为我们的工作流程提供更大的灵活性，并且最终也更易于管理。 一种非常方便的方法是定义用于包装实际命令的shell脚本，例如如何启动Docker容器，如何设置Docker compose，如何启动Kubernetes和应用YAML文件，否则，只需在该脚本上执行脚本即可。开发会议开始。 由于系统测试具有独立的生命周期并连接到已经在运行的环境，因此它们可以非常快速地运行。 专用测试环境和本地设置均可实现。 在本地设置复杂的环境听起来像是改变某些行为并验证我们的更改的大转变，但是，具有热部署技术的现代开发工具可帮助我们保持周期的Swift。 我们可以立即修改被测应用程序的行为，然后重新执行测试用例，这也可以非常快速地运行。
这种方法为我们提供了非常快速的反馈，但经过了适当的验证，因为我们是针对实际的应用程序界面而不是仿真进行测试。 但是，至关重要的是我们必须保持设置的可维护性，以使复杂性可管理。
在本系列文章的下一部分中，我们将介绍有效的开发工作流程以及测试代码质量的重要性以及如何实现测试保持可维护性。
翻译自: https://www.javacodegeeks.com/2019/09/efficient-enterprise-testing-integration-tests-3-6.html