沙箱降低了设置类生产环境的成本和复杂性，使各种规模的团队都能够在真实环境中有效地进行测试。
译自 Why Mocks Fail: Real-Environment Testing for Microservices，作者 Anirudh Ramanathan。
“尽管我们所有的单元测试和集成测试都通过了，但我们在预发布环境中看到了很多流程中断。团队需要花费数天时间在那里进行调试。” 这位来自一家拥有 100 多个微服务的金融科技公司的工程副总裁坦言，这是一种常见的挫败感。虽然单元测试和契约测试显示一切正常，但实际的集成问题却不断涌入预发布环境。
当工程团队采用微服务时，测试策略通常以 Mock 为中心和模拟。这似乎是“左移”的理想方式，使开发人员能够在周期的早期验证功能，而无需等待完整的环境。但是，当 Mock 成为主要的测试策略时会发生什么？
Mock 本身并没有缺陷，但团队通常将 Mock 视为真实系统的高保真表示。现实情况是？在许多服务中维护 Mock 是一项艰巨的任务。API 更改和不断发展的业务逻辑会在 Mock 和真实系统之间产生偏差，从而导致 Bug 泄露。
Mock 擅长测试负面案例和需要非常特定输入的场景。它们允许团队验证隔离的功能并有效地重现边缘情况。但是，真实世界的复杂行为（例如动态依赖链和细微的 API 交互）通常无法以足够的保真度进行模拟。但是，随着微服务生态系统的复杂性增长，仅靠 Mock 无法：
- 捕获真实世界的交互： 依赖链和网络效应很难模拟。
- 动态适应： 随着 API 的发展，Mock 需要不断更新。
- 尽早发现集成问题： 如果没有真实的依赖项，许多集成故障在预发布环境之前都不会被注意到。
这种过度依赖会导致双重打击：维护 Mock 的成本和在预发布环境中调试集成故障的开销。
“左移”不必意味着“更多 Mock”。它是关于将有意义的反馈转移到开发周期的早期。将 Mock 与真实环境反馈相结合的混合方法提供了两全其美的优势：
- 使用 Mock 处理需要受控输入的边缘情况和场景。
- 利用真实环境 针对真实的依赖项验证集成流程、复杂的 API 行为和性能特征。
真实环境测试对于解决 Mock 的局限性非常宝贵，尤其是在验证复杂的 API 行为时。但是，由于以下原因，历史上维护用于测试的高保真环境一直具有挑战性：
- 成本： 建立和维护逼真的环境成本很高。
- 运营复杂性： 管理和扩展此类环境会带来巨大的开销。
- 争用： 共享环境会在多个团队争夺资源时造成瓶颈。
由于 沙箱 之类的方法，在真实环境中进行测试变得越来越容易。这种方法消除了设置类似生产环境的高成本和复杂性，使各种规模的团队都可以在真实环境中有效地进行测试。
以下是沙箱如何应对常见挑战：
- 验证契约： 在共享环境的隔离切片中，针对实时下游依赖项测试 API 更改。
- 发现集成问题： 尽早检测并解决流程中断，而无需等待预发布环境。
- 扩展性能测试： 模拟真实的流量模式，而无需复制完整的环境。
借助沙箱，每个更改都有其自己的隔离测试空间，使团队可以高效且无争用地运行真实环境测试。这种方法减少了对高保真场景中 Mock 的依赖，从而在开发周期的早期带来了真实世界的反馈，同时控制了成本。
Mock 仍然是测试工具箱中的宝贵工具，但它们并非万能的解决方案。真实环境反馈对于捕获集成问题和验证系统行为至关重要，而这是 Mock 无法复制的。通过采用具有真实环境测试的混合方法，工程团队可以减少预发布环境瓶颈，提高开发人员的速度，并对其微服务更有信心。
准备好提升您的测试策略了吗？ 尝试使用 Signadot Sandboxes 进行测试，以验证真实环境中的合约、集成流程和性能。 了解如何尽早发现问题并自信地交付。