实际上值得对API客户端进行单元测试吗？

这已经让我困扰了一段时间。实际上值得对API客户端进行单元测试吗？

假设您正在创建一个小类，以抽象化对petshop REST API的调用。petshop是一个非常简单的API，它具有一组基本方法：

• listProducts()
• getProductDetails(ProductID)
• addProduct(...)
• removeProduct(ProductID)

在测试时，我们必须创建一个模拟服务或模拟响应。但这似乎太过分了；我知道我们想确保我们的方法不会因拼写错误/语法错误而停止工作，但是由于我们正在编写调用远程方法的函数，然后又从这些远程方法创建虚假响应，因此看起来浪费了很多精力，而我们正在测试的是不可能真正失败的东西。更糟糕的是，如果更改远程方法，则在生产使用失败时，我们的单元测试将通过。

我很确定自己丢失了某些东西，或者棍子的末端错了，或者我没有看到树木的木头。有人可以让我走上正确的路吗？

远程API客户端的工作是发出某些调用-不多也不少。因此，其测试应验证是否发出了这些呼叫-不多也不少。

当然，如果API提供者更改了其响应的语义，那么您的系统将无法生产。但这不是您的客户班的错。这只能在集成测试中发现。通过依靠不受您控制的代码，您已经放弃了通过内部测试验证正确性的能力-这是一个折衷，这就是价格。

就是说，测试仅包含到另一个类的委派的类可能是低优先级的，因为复杂错误的风险相对较小。但这适用于仅由统一的一线组成的任何类，它与调出另一个供应商的代码无关。

简短答案：

所有方法都应进行单元测试。

长答案：

是。这是值得的。

这些是在这些API调用方法上进行的单元测试应测试的一些内容：

• 您正在向API调用传递格式正确或正确的参数。
• 您是否对API返回的某些类型的数据做出了相应的响应（无论是否模拟），例如，当API返回空字符串时，您的方法应返回默认值（仅作为示例）
• API调用时调用方方法行为正确，产生错误

这些就是所谓的方法所做的事情，可以在模拟API服务时将它们隔离开来，并且通过对它们进行良好的测试，可以确保错误不是由调用API的客户端代码中的错误引起的。

这些将不是单元测试，因为您正在测试系统的输入和输出，更像是有限集成测试。

当您说“这看起来确实是在浪费精力，而我们正在测试无法真正失败的事物”时，请务必谨慎-可能会失败，可能会失败，可能会以您无法预料的方式失败，如果您没有适当的测试，那么失败将更加严重。

您在这里犯的错误是与wheel的发明有关的：调用远程服务和API是一种非常常见的情况，因此有一些相当不错的工具可以帮助您进行测试。上一次我在连接到远程服务的应用程序上工作时，我使用了SoapUI它可以查看服务，并对该服务进行模拟调用，或者充当服务器的本地副本，您可以对服务器进行测试调用并跟踪请求和响应。设置花费了几分钟，并且如果远程接口发生更改，更新也非常快。我没有在REST场景中使用过它，但是即使它不能很好地工作（或者也许将来有人在更好的工具存在时阅读此答案），您也应该能够找到可以模拟的工具为您提供的服务，当需要部署代码时，您一定会很高兴。