应该何时编写BDD测试方案？

Question

我正在调查scrum场景中的BDD测试，并意识到BDD场景更像是规范而不是测试。

因此，应该在开发人员进入预先规划之前编写它们，以便确定所有功能，以便在会议中更好地估算，确定优先级等？

Answer 1

如果BDD你的意思是“行为驱动的发展”，那么你可能会因为“测试”这个词而被绊倒。

它们不是测试，即使您将从中获得免费测试。如果您将它们视为测试，则会严重使用它们。

它们是规格。如果以这种方式接近它们，您可以看到它们如何适合您的过程。

这取决于你，但是你会通过强迫自己远离将它们视为测试来获得最大的好处，而是将它们视为规范。没有什么可以阻止你滥用它们（作为测试），但滥用它们将保证你不会从这种方法中获益 - 而且它是实质性的。

Answer 2

通常，在Scrum中，您希望具有满意条件的用户故事与它们一起使用。这意味着，如果符合这些条件，我作为产品负责人将会对故事的完整性感到满意。

最好是由产品负责人编写，如果以Given / When / Then格式编写，则更好。这样，团队可以根据满意度条件创建BDD测试。测试通过后，故事就完成了。

应该有尽可能多的满意条件，因为产品负责人认为有必要确认故事已经实施，并且应该及时为sprint计划会议准备这些条件。它们不需要编码，但应该写出来，以便团队知道完成故事的预期。

团队可能会在sprint期间添加自己的BDD测试，但是在最初的BDD测试通过之前，故事还没有完成。

Answer 3

如果您正在寻找BDD（也称为验收测试驱动开发），您可能愿意在Sprint计划开始之前尽早开始编写验收测试。其他一些“更灵活”的方法倾向于将此推迟到最后一个负责任的时刻，我一直在指导几个团队，其中接受标准随着时间的推移也在Sprint期间得到改进。

开发团队的“测试人员”在准备下一个Sprint的Backlog（称为预测）期间与产品负责人密切合作，并且在当前冲刺期间，他们在看到时充实了验收标准符合PO。

这在很大程度上还取决于你如何执行这些测试...如果你能够自动化，那么事情要清楚得多:-)我们广泛使用Cucumber或Fitnesse来自动化验收测试，并且你会做TDD（没有A）你会在承诺发生之前尝试做到这一点，至少在基本层面（你不需要定义所有这些 - 记住它看起来不应该像合同）

BDD的目标是从行为角度推动软件的开发，这应该为您提供一个非常明确的“方式”，即如何以及何时编写接受标准。我发现它们与用户故事的INVEST清单以及Ready for you Backlog的定义非常有用。

HTH ANdreaT

Answer 4

我希望你提到行为驱动开发。如果我​​是对的，这是一个与开发人员，QA和非技术或业务参与者互动的过程。它也是开发人员代码的目的和好处。您可以在预先计划时启动Scrum场景。

估算和优先排序不在其中。