微服务架构的一个主要方面是应用程序形成为松散耦合的服务的集合,每个服务可以独立地部署并且通过某种轻型协议相互通信。
现在假设您要为Cart Service编写端到端测试。您很快就会发现它并不容易,让我列举一些原因:
因此,端到端测试不是测试微服务的最佳方法,但您仍需要一种从服务的开始到结束进行测试的方法。
有必要找到一种“模拟”这些外部依赖关系的方法,而不必注入任何模拟对象。我们需要做的是欺骗被测服务,因此它确实认为它正在与真实的外部服务进行通信,而实际上并非如此。
允许我们这样做的方法是Service Virtualiztion。服务虚拟化是一种模拟组件应用程序(如基于API)的行为的方法。
您可以将服务虚拟化视为您过去在OOP中实现的模拟方法,而不是在对象级别进行模拟,而是在服务级别进行模拟。这是对企业的嘲弄。
有很多服务虚拟化工具,但根据我的经验,在JVM生态系统中,更好的工具之一是Hoverfly。
让我们看看Cart Service的“端到端”测试是怎样的。
这个服务是使用Spring Boot实现的,所以我们使用的是Spring Boot Test框架。这里的重要部分是使用CATALOG_ENDPOINT属性指定部署Catalog服务的URL 。对于此测试,它设置为目录。
下一个重点是Hoverfly类规则部分。在该规则中,指定了以下内容:
测试本身只使用TestRestTemplate(它是一个休息客户端)并验证您可以向购物车添加一些元素。
请注意,您无需配置启动HTTP代理的位置或配置任何端口,因为Hoverfly会自动配置JVM网络参数,以便任何网络通信都通过Hoverfly代理。
请注意,现在您不需要知道如何启动Catalog服务,也不需要知道如何使用正确的数据对其进行配置。
您正在其边界内测试整个服务,从传入消息到传出消息到其他服务,而不模拟任何内部元素。
您可能想知道“如果当前服务还依赖于数据库服务器会发生什么?”
在这种情况下,您什么也不做,因为服务本身知道正在使用哪个数据库服务器以及它需要的数据类型,您只需要启动数据库服务器,填充所需的数据(夹具)并执行测试。对于这种情况,我建议您使用Arquillian Cube Docker从Docker容器启动数据库服务,这样您就不需要在需要运行测试的每台机器上安装它,而Arquillian Persistence Extension则用于将数据库维护到已知状态。
在下一个评级服务示例中,您可以简要了解如何将它们用于持久性测试:
通过这种方法,您可以确保服务的所有内部组件按预期工作,并避免微服务中端到端测试的片状性质。
因此,任何微服务中的端到端测试与整体应用程序中的端到端测试并不完全相同; 您仍在测试整个服务,但保持受控环境,其中测试仅依赖于服务边界内的组件。
合同测试如何适应?那么,这里显示的所有内容都可以用于合同测试的消费者和提供者方面,以避免启动任何外部服务。通过这种方式,正如许多作者所总结的那样,如果您使用合同测试,这些将成为新的端到端测试。
原文标题《Writing End to End Tests for a Microservices Architecture》
作者:Alex Soto
译者:February
不代表云加社区观点,更多详情请查看原文链接
本文系外文翻译,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系外文翻译,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。