在许多方面，测试微服务应用程序与测试使用任何其他体系结构构建的应用程序没有什么不同。微服务面临的独特挑战是组成应用程序的服务数量之多，以及服务之间的依赖关系数量。
作为用于构建复杂系统的体系结构，微服务在开发社区中获得了巨大的关注。尽管人们开始意识到这并不是解决所有应用程序体系结构问题的灵丹妙药，但是那些与依赖项和扩展性相关的挑战共享的应用程序可以从中受益匪浅。
微服务的采用正在上升，但是与了解如何测试微服务相关的斗争也在增加。ThoughtWorks的Toby Clemson在列举您可能希望在微服务体系结构中使用的测试策略方面做得非常出色（请参阅他的文章，以获取有关您可能要创建的不同测试类型的详尽概述），但是有关如何建立和维护那些不同种类的测试仍处于起步阶段。
但是在许多方面，测试微服务应用程序与测试使用任何其他体系结构构建的应用程序没有什么不同。微服务使用众所周知的技术，例如REST或队列，为此软件行业已经拥有完善的测试工具和最佳实践。微服务面临的唯一挑战是构成应用程序的服务数量之多，以及服务之间的依赖性。此外，即使微服务依赖的其他微服务不可用或响应不正确，每个微服务仍需要正常运行。
微服务在相互交互时通常遵循两种模式：编排和响应式（编排）。许多微服务使用组合的“混合”方法。在本文中，我将提供一些策略来解决在使用这些不同模式的微服务创建自动化测试时出现的一些挑战，重点是针对单个微服务的测试（而不是整个应用程序的端到端测试） 。
使用业务流程的微服务将对外部服务或依赖项进行一个或多个显式调用。这些调用通常使用同步请求-响应流，并且通常将访问基于REST的服务。如果需要按特定顺序调用服务，则在收到对前一个服务的调用的响应之前，不会进行对后一个服务的调用。由于一项服务显式调用另一项服务，因此它们紧密耦合。
在上面显示的示例中，为投资组合微服务创建和执行测试具有挑战性，因为投资组合微服务依赖于帐户和报价微服务，而依赖项需要与投资组合微服务一起部署在测试环境中。Quotes服务依赖于第三方服务来检索实时股票价格，并且该服务返回的数据始终在变化。
依赖第三方服务或由不同团队开发的服务极大地增加了测试环境的复杂性。此外，还需要测试投资组合服务的任何意外行为，例如，当“帐户”和/或“报价”服务不可用，响应缓慢或响应意外数据时。重要的是，必须使这些服务以不同的意外行为响应，以验证Portfolio微服务正确处理了错误情况。
服务虚拟化急救
