为第三方提供可测试的Web服务

Question

从我的观点来看，申请如下：

我正在制作的应用程序（我们称之为App1）和两个第三方App2和App3。

• App2 ：想要从App1中使用简化的网络服务
• App1 ：这就是我所在的地方。来自App3的服务在这里处理得很好，有一个漂亮，干净的内部API，方便使用。
• App3 ：第三方服务提供商。复杂的服务。重点：没有测试环境，我们所做的一切都是通过生产数据来完成的（尽管通常使用单独的测试帐户）。如果我们搞砸了，现实世界中真实的人会发生一些事情。缺乏真正的测试环境不在我的掌控之中。

App3为我的应用程序App1提供了一些Web服务。 App2希望我以更简单的方式“转发”这些服务，因此他们不必重新实现我已经处理过的复杂性。但是，消费我的Web服务的App2需要在实现他们的一方时使用这些服务的可测试版本，以便自己处理不同的用例。

如何尽可能顺利实施？

在内部，我现有应用程序的相关部分看起来大致如下：

• 演示文稿+网络服务（网络应用程序+小型网络API，现在也是此网络服务）
• 以下服务的服务外观（为App3提供的服务提供干净的API）
• 服务（解析，映射，日志记录，来自App3的SOAP调用的一些诊断） - 排序“数据层”

Web服务本身很好，通常只是直接与服务外观交谈。但是，这将使App2只使用生产数据来测试他们的服务（而且这种服务无法在生产数据上进行测试，这是一种严酷的写入操作）。因此，例如，当设置了给定的配置参数时，我可以告诉我的IoC容器使用相关服务外观的单独实现。但是，由于我只是“转发”这些服务的有限子集，这将使得使用该服务外观的应用程序的其余部分在我们的测试环境中无法使用，这不是一件好事 - 其他东西需要是测试（甚至是生产数据）。

我正在考虑在演示文稿/ Web服务层和服务外观之间引入另一层，只有这个Web服务才能使用。然后让IoC容器在部署到测试环境时调整其测试版本。

关于它的好东西：

• 它允许我为第三方提供所有提供的Web服务，从外部看到一个完全可测试的状态，我可以在内部使用其他不同的东西来模拟不同的用例。
• 它可以使应用程序的其余部分保持原样，使用App3中的实际生产服务，在其他地方进行测试。
• 将使这个新层单元的可测试版和“真实交易”版本都可测试

坏事：

• 创建另一层看似不必要的复杂性，而不是真正给应用程序本身提供任何东西
• 需要一些机制来打开/关闭测试模式（=更多垃圾代码/配置）
• 类似垃圾的代码，人们可能会错误地在一两年之后进行原型设计，试图摆脱原型

我在考虑正确的事情，还是有其他（显着）不同的解决方案？

• 发送单独的参数以启用测试模式？看起来有风险，而且还有更多的工作在我身边。

Answer 1

  

App2 [...]需要使用这些服务的可测试版本   在实施他们的一面时，处理不同的用例   本身

目前还不清楚你想在这里测试什么。

如果你的意思是测试App2与App1配合得很好，我倾向于认为让自己“可测试”不是第三方组件的工作 - 它应该是测试与3d通信的消费者组件派对并验证它是否能够处理其结果。

在App2中，为App1的服务创建代理。在单元测试中，您可以存根代理的方法来返回预设的测试数据。这些数据可能或多或少地接近生产数据，具体取决于您要覆盖的方案。然后在代理和真实服务之间创建集成测试，以验证一切运行顺利。