做网站的步骤 优帮云,网站建设移交确认书,技术先进的网站建设公,汕头网站建设制作报价本系列的这一部分将展示如何通过代码级以及系统级集成测试来验证我们的应用程序。 #xff08;代码级#xff09;集成测试 集成测试一词有时在不同的上下文中使用不同。 根据Wikipedia的定义#xff0c;我指的是在代码级别上验证多个组件之间相互作用的测试。 通常#x… 本系列的这一部分将展示如何通过代码级以及系统级集成测试来验证我们的应用程序。 代码级集成测试 集成测试一词有时在不同的上下文中使用不同。 根据Wikipedia的定义我指的是在代码级别上验证多个组件之间相互作用的测试。 通常集成测试利用嵌入式容器或其他模拟环境来测试应用程序的子集。 诸如Spring TestsArquillianCDI-Unit之类的测试技术使编写测试变得容易并且易于将各个类注入测试类以在测试执行期间进行直接交互。 下面显示了使用CDI-Unit运行器的集成测试的伪代码示例 测试方案可以轻松注入和模拟依赖项并可以在测试方法中访问它们。 由于嵌入式测试技术需要花一些时间才能启动因此嵌入式集成测试通常对整个测试执行时间有最大的负面影响。 根据我的经验许多项目会复制并粘贴现有的测试方案并以每种测试类都会重新启动应用程序或其一部分的方式运行它们。 随着时间的推移这会大大增加构建的周转时间以至于开发人员将无法获得快速的反馈。 尽管这些类型的测试可以验证“管道”的正确性但是API和注释是否被正确使用它们并不是测试业务逻辑的最有效方法。 尤其是在微服务应用程序中集成测试不能提供最终的信心尤其是端点和持久性的集成是否会像生产环境中那样完全。 最终在映射JSON对象处理HTTP请求或将对象持久保存到数据存储的方式上总会有微小的差异。 问题总是我们的测试应该真正验证什么。 我们是否正在验证框架框架的正确用法或整个应用程序的正确行为 代码级集成测试很好地工作可以快速反馈开发人员在连接框架时是否犯了一些粗心的错误。 在这种情况下一些单个测试用例不能验证业务逻辑而只是能够以冒烟测试的方式启动应用程序就可以提高开发效率。 但是如果我们的应用程序没有以过于复杂的方式利用我们的企业框架例如使用自定义限定符CDI扩展或自定义范围那么对代码级集成测试的需求就会减少。 由于我们有使用系统测试来捕获相同类型错误的方法还有许多其他方法因此我通常不鼓励开发人员编写过多的代码级集成测试。 集成测试确实使在代码级别上连接多个组件变得容易但是可以使用不同的方法例如用例测试而这些方法并不会增加启动时间。 由于集成测试技术通常会启动或部署到容器中因此它们通常会定义自己的生命周期因此很难将其集成到更大的画面中。 如果开发人员想要制定优化的开发工作流程则需要以一种模式运行应用程序该模式可以在不同生命周期中热重新加载更改然后针对正在运行的应用程序快速执行集成测试而通过这些类型的集成测试很难做到这一点。 因为他们通常会启动自己的应用程序。 有一些技术可以改善这一点例如Quarkus及其集成测试。 尽管如此一种更简单更灵活的方法是将测试方案与整个应用程序上下文的生命周期分开。 与嵌入式应用程序生命周期纠缠在一起的测试还使得很难在多个范围内重用测试方案因为它们通常需要使用特定的运行程序或其他约束来执行。 在很多情况下重用测试场景定义测试逻辑部分的代码在不同的范围内简化了增强测试套件的过程例如用于用例测试负载测试或系统测试。 如果这些案例对如何执行没有太多限制例如与哪个测试运行程序一起使用重用它们即将它们复制到其他位置并交换使用的委托或组件的实现则变得更加简单。 正如您将在以下内容中看到的有很多有效的方法可以完全验证我们的应用程序尤其是对于更复杂的项目。 系统测试 在微服务世界中我们的应用程序越来越多地与其他资源例如外部系统数据库队列或消息代理集成在一起并且通常包括不太复杂的业务逻辑。 话虽如此从外部角度验证我们系统的行为至关重要也就是说以与生产中其他组件相同的方式与我们的应用程序进行交互。 系统测试通过使用常规接口例如HTTPgRPCJMS或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
