我对TDD与BDD感到困惑:) TDD和BDD在以下各点有何不同？
RestService（HTTP）：不要进行休息通话？如果是的话，
a）我们是否只使用模拟对象返回硬编码的json？
b）如何处理REST呼叫失败？我们也应该有测试用例吗？
特别是对于第2项，我搜索了很多文章，但无法找到关于如何处理休息呼叫的示例（代码）方法。
答案 0 :(得分：0)
BDD和TDD彼此不具有可比性，尽管它们都用于测试第一次开发。
BDD不仅仅是用类似英语的语法编写测试，例如：猕猴桃。 BDD（也称为ATDD-验收测试驱动开发）从开发人员，QA和设计人员（例如业务和交互设计人员）开始，共同致力于开发对所提议解决方案的共同理解。通常使用示例来说明行为，也称为示例规范。
我发现一种思考抽象的有用方法是区分你所做的事情（抽象的，高级的政策），以及你如何做（具体的，低级的细节）。每个具体细节都存在，以实现更高层次的政策。当您看到具体的内容时，确定其所服务的政策是有益的。
通过示例的规范可用于创建高级验收测试，测试应用程序的功能，即其行为。
单元测试用于测试应用程序如何实现解决方案，即测试在适当的时间将相应的消息发送给其协作者/依赖关系。
标准TDD循环的阶段是红色，绿色，重构。在绿色阶段，你的目标是通过钩子或骗子尽快让测试通过 - 编写丑陋，无组织的代码是可以接受的。测试通过后，您重构代码以使其更具可读性/可更改性。
同样，对于BDD / ATDD循环，您有红色，绿色，重构。在BDD的绿色阶段，只需通过验收测试。您编写的所有代码都可以存在于测试本身中。在BDD的重构阶段，您将测试代码提取到生产代码中。您可以使用TDD来指导提取。
因此，对于给定的BDD验收测试，您可能会进行多次TDD测试。
关于如何测试REST调用，让我们回到抽象的前提 - 区分我们的工作方式。
调用REST服务是一项具体行动。它满足的策略可能是提供模型对象列表。
让我们说你正在实施的用例是邀请朋友共进午餐。用例责任的一部分是从服务器获取朋友列表;它并不关心服务器如何找到朋友。
您的BDD测试将处理获取朋友列表，挑选朋友以及完成邀请。您的BDD测试不会担心实际进行REST调用。
当您使用TDD实现处理与服务器通信的类时，您可以使用从远程数据源（即服务器）检索JSON的测试，并确保将JSON正确解析为User模型对象。您还可以通过测试来覆盖响应错误的数据源等。
在您实际进行REST调用时，在使用REST与后端服务器通信的远程数据源的实现中，我将其归类为集成测试，因为您正在测试与组件的集成不要控制，即实际的后端服务器。集成测试只需要确认服务器以您的应用程序期望的格式返回JSON数据，或者在适当时返回错误。
答案 1 :(得分：0)
BDD实际上是derived from TDD，所以这并不奇怪，这有点混乱！ BDD与TDD（或ATDD，如果您正在为整个系统进行）完全相同，但没有单词＆＃34; Test＆＃34;。事实证明，这可能非常强大。
特别是，它允许开发人员与非技术业务人员讨论系统应该做什么。您也可以使用它来讨论类应该做什么，或者代码模块应该做什么，即使是技术专家也是如此。
因此，在您的REST服务示例中，您可以想象我是一名开发人员，您是了解REST服务应该做什么的专家。
我：该怎么办？ 你：应该让我读一条记录 我：太棒了！你能给我一个记录的例子吗？ 你：我在这里有一个...
我：是否存在某人无法阅读记录的情况？
您：当然，如果他们没有权限。...
我：好的，所以我已经完成阅读，让我们做更新。你能给我一个典型更新的例子吗？ 你：你走了。
我：太棒了，你希望它只是成功或失败。是否存在 失败的情况？ 你：当然。记录显示上次更新的时间。如果其他人在此期间已经更新了它，那么在提交时你的用户就会失败。
所以你看到你可以使用BDD来探索各种场景，包括那些围绕REST服务的场景。诀窍是问，＆＃34;你能给我一个例子吗？＆＃34;然后你得到一个具体的例子，如果你愿意，你可以自动化。这些对话有助于我们查找其他示例和我们可能错过的场景。
不要使用BDD工具为技术受众自动化！像Cucumber，JBehave等BDD工具使用真正的英语，比代码更难以重构。如果您正在执行类似REST服务的操作，请使用JUnit，NUnit等。你可以把＆＃34;给定，何时，然后＆＃34;在评论中，或做一点DSL。
所以现在你可以看到，当你的REST调用失败时，如果我编写它，我会有一个例子：
我：所以，这次通话失败......你能举个例子吗？ 您：当然，如果您访问已被删除的记录，它将会失败。
我：给我一个可能被删除的记录的典型示例？ 你：我们之前使用的那个很好 我：好的，是否存在我们不应删除记录的情况？
您：是的，如果它已经发布......
等
你可以看到，在整个过程中，我并没有真正使用＆＃34; test＆＃34;这个词。测试是BDD中不错的副产品。它更多地用于探索和规范要求。 BDD中的对话是其中最重要的部分。
找到使用BDD for REST的示例很棘手的原因首先是因为REST故意简单并且通常不会有很多行为，其次是因为BDD的场景不是＆＃ 39;通常用它们的实现来表达，而是关注服务或系统提供的价值（＆＃34;读取记录＆＃34;）。
如果他们做得好，TDD和ATDD完全相同。与示例和场景的对话比让它们进行测试更容易。