生产测试：使用 JSON Schema 进行 3rd 方 API 响应验证

Submotion 提供了一个管理 SaaS 帐户和订阅的中心位置。这是通过连接到一堆第三方 API 来实现的。一个惊人的事实是，这么多公司公开 API 允许您与他们的服务集成，以实现互惠互利。使用这样的 API 是相当简单的，即使像 OAuth 实现这样的东西经常与标准不同，但设置起来通常并不难。在 CI 设置中，正确的端到端测试是不可行的。它不仅速度慢，而且依赖于对可能出现故障的外部服务器的访问，而且几乎不可能设置有用的装置。最初我试图建立一个记录/回放系统来缓解这种情况。这在某些情况下效果很好，但 Submotion 几乎总是通过 OAuth 连接，这很难自动化（按设计），即便如此，我仍然遇到固定装置的问题。我想测试 Submotion 是否检测到某个帐户已被删除。为了做到这一点，我必须在 Slack 或其他任何东西中创建并随后删除一个帐户，这是一项非常复杂的任务。所以我放弃了这种方法，有一段时间我只是承认模拟是我能做的最好的。事实上，我仍在编写手动模拟，但我确实设法改善了这种情况。我正在和我的朋友 Lars 讨论这个问题，他对这些和类似的问题进行了很多思考。他建议我将断言从测试转移到生产代码中。现在，我记得在 C++ 中做了很多这样的事情，其中​​断言在调试版本中很常见，然后在生产中被删除。然而，这感觉不像是 Node 原生的方法，它以某种方式让我感到不适。但是，正如他所指出的，这样的断言可能只是在生产中记录警告，并且在本地或通过测试运行时，它们可能会抛出。这样，我将持续对真实响应运行验证，这意味着所述验证是最新的并且足以保持我的模拟数据健全。尽管这是严格验证，但对我来说仍然感觉像是解析的变体，不要验证 Alexis King 创造的哲学。虽然它仍在进行中，但到目前为止，这是向前迈出的一大步。向相关的第 3 方 API 发出一两个请求，并将 JSON 响应保存在文件中。这是草图。清理架构。它们很少能从单个响应中正确推断出来，因此需要进行一些调整。值得注意的是，我在适用的情况下为电子邮件、URL 或 IP 地址等内容添加了格式字段。然后，在发出请求后立即使用 AJV（带有 ajv 格式）来验证响应。如果验证失败，记录一个错误，或者，如果运行测试，抛出一个异常

最后，将 as-typed 与 schema 一起使用以获得类型化的响应。它并不完美，但比无类型的要好得多，我可以确信我的运行时验证与类型检查一致。当然，模式验证/类型检查只查看响应的形状，这意味着语义错误仍有很多空间。没有什么能阻止我用更多的语义断言来扩展这个设置，这将进一步提高质量，但我还没有真正找到我的最佳位置。也许在以后的帖子中。