从我的角度来看，应用程序如下：
我正在制作的应用程序（我们称之为 App1）和两个第三方 App2 和 App3。
- App2：想要使用来自 App1 的简化 Web 服务
- App1：这就是我所在的位置。来自 App3 的服务已经在这里得到了很好的处理，带有一个漂亮、干净的内部 API 以便于使用。
- App3：第三方服务提供商。复杂的服务。重要的一点：没有测试环境，我们所做的只是使用生产数据（尽管通常使用单独的测试帐户）。如果我们在这里搞砸了，事情就会发生在现实世界中的真实人物身上。这种缺乏真正的测试环境不在我的控制范围内。
App3 为我的应用程序 App1 提供了一些 Web 服务。App2 希望我以更简单的方式“转发”这些服务，因此它们不必重新实现我已经处理过的复杂性。但是，将使用我的 Web 服务的 App2 需要有这些服务的可测试版本，以便在实现它们的时候使用，以自己处理不同的用例。
如何尽可能顺利地实施？
在内部，我现有应用程序的相关部分大致如下所示：
- 演示文稿 + Web 服务（Web 应用程序 + 一个小型 Web API，现在还有这个 Web 服务）
- 以下服务的服务外观（为 App3 提供的服务提供干净的 API）
- 服务（解析、映射、日志记录、对来自 App3 的 SOAP 调用的一些诊断）——类似于“数据层”
Web 服务本身很好，通常只是直接与服务门面对话。但这会让 App2 只剩下生产数据来测试他们的服务（而且这个服务不能在生产数据上测试，这是一个苛刻的写入操作）。所以我可以告诉我的 IoC 容器在设置了给定的配置参数时使用相关服务外观的单独实现。但是，由于我只会“转发”这些服务的有限子集，这将使使用该服务外观的应用程序的其余部分在我们的测试环境中无法使用，这不是一件好事 - 其他东西需要经过测试（甚至针对生产数据）。
我正在考虑在表示/Web 服务层和服务外观之间引入另一个层，只有这个 Web 服务使用。然后让 IoC 容器在部署到测试环境时提供一个测试版本。
关于它的好处：
- 它让我可以将所有为第三方提供的 Web 服务置于从外部看到的完全可测试的状态，在那里我可以在内部使用 if-else 不同的东西来模拟不同的用例。
- 它使应用程序的其余部分保持原样，在必要时使用来自 App3 的实际生产服务进行测试。
- 将使这个新层单元的可测试版本和“真实交易”版本都可测试
坏事：
- 创建另一层看似不必要的复杂性并没有真正为应用程序本身提供任何东西
- 需要一些机制来打开/关闭测试模式（= 甚至更多的垃圾代码/配置）
- 类似垃圾的代码，人们可能会在一两年后误认为是原型，试图摆脱它
我的想法是正确的，还是有其他（明显）不同的解决方案？
- 发送单独的参数以启用测试模式？似乎有风险，而且我也喜欢更多的工作。