1

我来自 python/django 背景。

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

对于通过 TDD 设计django 民意调查应用程序，我将如下所示：

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

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

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

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

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

根据我的阅读，我可以得出的是，如果我设计一个 django 民意调查应用程序，我必须遵循的过程如下：

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

  2. 编写步骤

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

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

请帮助我消除我的困惑，并提出一个简短的大纲，

请让我知道，我该如何继续。当我们执行django polls 应用程序时，尝试 BDD 的顺序方法是什么。

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

4

1 回答 1

1

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

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

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

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

我通常的工作方式是这样的：

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

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

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

于 2012-09-21T08:03:50.860 回答