Node/Mocha：如何测试调用外部 API 的包装器方法答案

【问题标题】：Node/Mocha: how to test a wrapper method that calls external APINode/Mocha：如何测试调用外部 API 的包装器方法
【发布时间】：2018-02-24 20:00:43
【问题描述】：

我最近开始编写单元测试，并开始转向集成测试。我有这个相当简单的方法，但我对如何接近甚至如何准确地测试它有点迷茫。

list (token, cb) {
  const requestArgs = {
    headers: { 'Authorization': `Bearer ${token}` },
    method: 'GET',
    uri: `${BASE_URL}/rest/V1/modules`,
    json: true
  }

  request(requestArgs, (err, msg, resp) => {
    if (err) {
      return cb(err) // library error
    }
    return cb(null, resp)
  })
}

通过阅读各种文章和 Sinon 文档，听起来我可能需要 request() 的“间谍”或“模拟”？即使我用良好的响应伪造了外部 API 调用，如果它总是返回良好的响应有什么好处，因为所有此方法所做的都是放在一起 requestArgs 并返回外部调用的响应。我对“stub”、“spy”和“mock”这些术语以及我需要为这个包装方法做什么感到困惑。

【问题讨论】：

查看这个 SO 问题了解 Mock、Stub 和 Spy stackoverflow.com/questions/24413184/… 之间的区别

标签： node.js unit-testing mocha.js integration-testing sinon

【解决方案1】：

有关 Mock、Stub 和 Spy 对象之间的区别，请参阅此 SO 问题。

Can someone explain the difference between Mock, Stub, and Spy in Spock framework testing and when to use them?

在您的单元测试中，您应该始终将测试范围限制在正在测试的特定单元。在您的情况下，我将存根“请求”函数，并返回我希望在不同场景中返回的任何数据。

这种方法具有许多优势，包括加快测试速度。访问外部资源通常很耗时。此外，由于您的测试范围缩小了很多，因此更容易查明问题。

如果您的测试范围包括一个以上的单元，那么这将被视为集成测试。集成测试旨在检查各个单元之间的通信流以及它们之间的数据流。

即使我以良好的响应伪造了外部 API 调用，又有什么好处呢如果它总是返回一个好的响应，它会这样做吗

您应该在尽可能多的不同场景中测试您的单元，以确保您的代码在您可能遇到的每种情况下都能正确运行。

您是否在每种情况下都在回调函数中收到正确的参数？是否返回错误？

将您的测试视为代码的实时文档。你的测试应该描述你的代码应该做什么。

例如，如果其他开发人员进行了重大更改，或者您在重构代码时意外引入了错误，您的测试应该能够捕捉到它。

【讨论】：