我正在围绕第三方 API 编写 PHP 包装器。对于练习来说更是如此，但我目前还没有在任何地方看到一个好的可用的，所以也许将来它会被其他人使用。
我的单元测试非常简单，但现在我已经达到了极限。
API 的开发人员有最大请求限制（每秒 1 个，每分钟 20 个），并且我的单元测试通过我的 API 包装器访问 API 端点，因此测试我的包装器。然而运行phpunit已开始返回429 too many requests错误。因此，Phpunit 显然正在运行我拥有的 15 个左右的测试，所有这些测试都访问端点太快并给我这个错误。
有谁知道我是否a）应该嘲笑这些回应, and b）如果我正在测试我的包装器，我将如何模拟响应？。如果测试没有在我的实际包装器对象上运行并且我肯定不想让我的包装器使用模拟响应，那么测试有什么用呢？
我是单元测试的新手，目前我对这个想法感到非常不舒服，但是我开始喜欢它了！
非常好的问题！当您刚开始测试时，这是一个常见问题。
首先区分单元测试和集成测试：
- 单元测试 - 单独测试一个“单元”，通常是一个类。大多数时候它是通过模拟或存根单元的依赖关系来实现的。此级别不应使用任何基础设施（网络、文件系统等）。
- 集成测试 - 测试组件如何相互交互。您可能会影响基础设施，但您仍然可以选择不这样做（以进行优化）。
我会做以下事情：
- 将 API 客户端实现为库并为其编写集成测试。这些集成测试将实际访问 API，并证明客户端按预期与 API 进行交互。每当 API 客户端发生变化时，我都会运行它们，或者定期运行它们，以确保我仍然与 API 兼容。这些测试不会像应用程序测试那样频繁运行，因为它们是单独测试套件的一部分。
- 在应用程序中引入一个抽象，让我能够为与 API 交互的任何内容提供替代实现。这样我就能够使用更简单的实现（例如内存中的测试）编写验收或其他类型的集成测试。
- 确保如果我在应用程序中对 API 客户端的工作方式做出假设，我有集成测试证明此假设是正确的。例如，如果我使用有效 ID 调用一个方法，它会返回一个对象。否则它会抛出异常。仅当我在某个地方进行了集成测试来验证它们时，我才能依赖这些规则。
嘲笑回应是一件棘手的事情。如果有一天你尝试这样做，当第 3 方 API 发生变化时，你就会遇到麻烦。如果你还想走这条路，看看https://github.com/coduo/tutu https://github.com/coduo/tutu.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
