鉴于我们要设计 django polls 应用程序，我们如何依次进行 BDD

Question

我来自 python/django 背景。

我一直在阅读有关 BDD 的文章，以及为什么它比 TDD 更棒。但我想到的几个疑问是，做 BDD 的理想方法是什么？是否排除编写单元测试？是否排除进行集成测试？我找不到实现 BDD 的答案或有组织的顺序路径。

为了通过 TDD 设计一个django polls application，我会这样做：

1. 为模型编写测试，然后使测试通过。

2. 为表单编写测试，然后让它们通过。

3. 为视图编写测试，然后让它们通过。

4. 为自定义模板标签和中间件编写任何其他测试，并让它们通过。

5. 从我开始编写视图开始，继续逐步编写集成测试。

根据我的阅读，如果我设计一个 django polls 应用程序，我必须遵循的过程如下：

1. 用小黄瓜语法编写场景

2. 编写步骤

3. 在步骤中可能使用一些断言（单元），基于 ui 响应（集成）

4. 不确定，下一步做什么/如何做，甚至第 3 部分是否正确。

请帮我解决我的困惑，并提出一个简短的大纲，

请告诉我，我该如何继续。当我们执行django polls application 时，尝试 BDD 的顺序方法是什么？

（我希望这个问题不是一个主观的问题，所以是一个很好的地方问这个问题，如果不是不要杀我。）

Answer 1

虽然 BDD 包含一些特定的技术实践（如场景引导的自动化、由外而内的开发、单元测试等），但其主要目标是改善项目内的沟通（包括非技术利益相关者）。

您首先收集规范 - 以示例的形式 - 通过与利益相关者讨论。这可以通过多种方式完成，这里最重要的是交谈。在这些讨论中，不要强迫他们或你自己编写小黄瓜有效的场景。只需捕获预期的行为以及接受标准（即系统必须遵循的约束）。

然后，您将正式确定方案，并 - 理想情况下 - 与业务人员一起审查它们。这个阶段很有趣，因为它将验证您（和团队）对规范的理解。你经常最终意识到你做了错误的假设:)

当您定义了一堆规范（功能）并就它们的优先级达成一致后，您就可以开始实际的开发过程了。

我平时的工作方式是这样的：

1. 运行一个场景，看看它的第一步未定义；
2. 为该步骤添加步骤定义；
3. 再次运行，发现由于缺少实现而失败；
4. 为缺少的系统行为编写一个单元测试/规范；
5. 运行测试，发现失败；
6. 让它通过；
7. 重构您的代码；
8. 再次运行场景
   • 如果某个步骤失败，请转到 #4
   • 否则，如果未定义步骤，请转到 #2
   • 如果您已完成此场景，请转到下一个 :)

这基本上是由外而内的开发。您可能已经注意到，第 4 步到第 7 步是通常的 TDD 循环。此工作流程的一个好处是您的 TDD 周期得到正确引导：您不必考虑下一步该做什么。由于场景故障堆栈跟踪，实际的下一个所需行为会明确显示给您。

当然，这是一种做事的方式。没有什么是一成不变的，你可以调整事情。