ios - TDD 与 BDD : REST Service

Question

我都对 TDD 和 BDD 感到困惑 :)
TDD 和 BDD 在以下各点有何不同？

开发:先测试用例，后开发

RestService(HTTP):不打休息电话？如果是这样的话，

a) 我们是否只使用模拟对象返回硬编码的 json？

b) 如何处理 REST 调用失败？我们也应该有测试用例吗？

特别是对于第 2 项，我搜索了很多文章，但找不到关于如何处理休息调用的示例(代码)方法。

Answer 1

BDD 和 TDD 不能相互比较，尽管它们都用于测试优先开发。

BDD 不仅仅是使用类似英语的语法编写测试，例如猕猴桃。 BDD(也称为 ATDD — 验收测试驱动开发)从开发人员、QA 和设计师(例如业务和交互设计师)开始，共同开发对提议的解决方案的共同理解。通常使用示例来说明行为，也称为通过示例说明。

我发现思考抽象的一个有用方法是区分你做什么(抽象的，高级策略)和你如何做(具体的，低级细节)。每个具体细节的存在都是为了实现更高级别的政策。当您看到具体的内容时，确定它所服务的策略是有益的。

示例规范可用于创建高级验收测试，用于测试应用程序的功能，即其行为。

单元测试用于测试应用程序如何实现解决方案，即测试是否在适当的时间将适当的消息发送给其协作者/依赖项。

标准 TDD 循环的阶段是红色、绿色、重构。在绿色阶段，您的目标是尽可能快地通过测试，无论是不择手段还是不择手段——编写丑陋、无组织的代码是可以接受的。测试通过后，您将重构代码以使其更具可读性/可更改性。

同样，对于 BDD/ATDD 循环，您有 Red、Green、Refactor。在 BDD 的绿色阶段，只需通过验收测试即可。您编写的所有代码都可以存在于测试本身中。在 BDD 的重构阶段，您将测试代码提取到生产代码中。您可以使用 TDD 来指导提取。

因此，对于给定的 BDD 验收测试，您可能有多个 TDD 测试。

关于如何测试 REST 调用，让我们回到抽象的前提——区分我们做什么和怎么做。

调用 REST 服务是一个具体的操作。它满足的策略可能是提供模型对象的列表。

假设您正在实现的用例是邀请 friend 共进午餐。部分用例职责是从服务器获取好友列表；它不关心服务器如何找到 friend 。

您的 BDD 测试将处理获取 friend 列表、挑选 friend 和完成邀请。您的 BDD 测试不会担心实际进行 REST 调用。

当您使用 TDD 实现处理与服务器通信的类时，您可以进行从远程数据源(即服务器)检索 JSON 的测试，并确保将 JSON 正确解析为 User模型对象。您还可以进行测试以覆盖响应错误的数据源等。

在您实际进行 REST 调用时，在使用 REST 与后端服务器通信的远程数据源的实现中，我会将其归类为集成测试，因为您正在测试与您不使用的组件的集成控制，即实际的后端服务器。集成测试只需要确认服务器以您的应用程序期望的格式返回 JSON 数据，或者在适当的时候返回错误。