在测试范围内验证微服务有多糟糕？ [JAVA]答案

【问题标题】：How bad is verifying a microservice in test scope? [JAVA]在测试范围内验证微服务有多糟糕？ [JAVA]
【发布时间】：2018-10-20 14:42:16
【问题描述】：

所以我得到了一个任务，我必须验证远程微服务的 REST 响应。现在，我构建了一个调用给定 REST 端点的应用程序，现在我必须验证结果。

我的问题是，我应该在哪里编写测试？如果我使用 Junit/TestNG 写入测试范围，它应该是带有模拟对象的单元测试，对吧？但在这种情况下，我无法正确测试远程服务。

使用 Junit 从测试范围调用真实服务是一种糟糕的模式吗？

谢谢！

【问题讨论】：

如果您打算编写单元测试，那只会很糟糕。您正在此处编写集成测试。但是，请记住，测试是在每个构建上运行的，因此外部服务中的故障会破坏您的构建。
谢谢，是的，它确实是一个集成测试。我怎么能在每次失败时不破坏代码的情况下做到这一点？
保持集成测试分开，这样它们就不会在正常构建期间运行。这与使用的技术无关，您仍然可以使用 JUnit 作为测试运行器。
在这种情况下我应该把它们放在哪里？超出测试范围？
我不知道你所说的“测试范围”是什么意思。如果你是这个意思，他们会进入另一个目录。

标签： java testing junit microservices

【解决方案1】：

这实际上取决于您需要做出的权衡取舍，而且通常很难达到可靠状态。例如，如果您想在 QA 中进行测试，但其他团队对 QA 是什么有不同的理念，并且碰巧像本地开发环境一样使用它，那么他们的服务可能会比其他情况下更频繁地失败。在这种情况下，当您想要使用其他团队拥有的真实服务运行集成测试时，您的测试可能不会太指示您的服务是否正确运行。在测试您的服务时，可能是服务依赖失败导致失败。

在这种情况下，我会模拟您的团队不拥有的下游服务，因为它超出了您的控制范围。这可能是通过启动一个响应 JSON 或 XML 有效负载的 Web 服务或您正在使用的服务响应的任何元语言来模拟它。它也可以在 request client 级别模拟它，这意味着发送请求的库的最低级别。

因此，这意味着发送到您的服务的请求将通过您的服务中的所有逻辑层，而不会对您的团队可以控制的最低部分进行任何模拟。它基于黑盒测试，其中服务依赖项被隔离，并假设其他团队正在正确地对其服务进行版本控制或提供向后兼容性。如果您曾经看过测试金字塔，那么这种类型的测试维护成本会更低。金字塔的要点是，您的测试越集成，维护和构建的成本就越高。

如果您想要更多保证，可以将其与合同驱动测试结合使用。本质上，另一个测试套件测试下游服务并确保它们仍然遵守您的服务所依赖的有效负载模式。这样，您可以将这两组测试解耦，而不必担心随之而来的所有逻辑。它在失败方面也更加透明，因为您将知道您的服务失败还是服务依赖失败。

这将是一种策略，我主张使用像 Cucumber 这样的验收测试框架来实际完成这项工作。 Cucumber 有许多变体，但本质上，您将编写由您选择的语言解析的行为驱动测试（甚至产品所有者也可以阅读）。详情见this链接。

【讨论】：