BDD可以在“之后”完成吗？

Question

单元测试是编写代码测试的一种做法。 TDD是在“之前”编写它们的做法。 BDD是编写行为/规范驱动测试的实践。我可以“在”之后写BDD还是我必须在“之前”之前写它？

如果您在“之后”编写BDD，并且它不是BDD，那么它的名称是什么？

Answer 1

根据行为驱动开发的定义，您无法在代码之后编写行为测试，但这并不意味着这样做无用。您可以从编写规范测试中获得更多好处，但它们仍然可用作应用程序的回归系统测试。因此，虽然您在技术上不是在练习BDD，但编写这些测试是一个好主意。 BDD的一大优势是它引导特定行为的发展，因此您稍后通过添加它们会失去很多价值，但它们仍然有用。

这与在TDD中的代码之后编写单元测试相同。从技术上讲，它不是TDD，但进行测试显然仍然有用。

Answer 2

行为驱动开发（BDD）是测试驱动开发（TDD）的变体，就像TDD一样，您应该首先编写测试。

有些人称BDD正确完成TDD，或者按照预期的方式。此外，您可以说BDD是域驱动开发（DDD）和TDD的混合。

Answer 3

开发后的BDD不是BDD，而是验证而非规范的情况。

然而，正如其他人提到的那样，并不意味着在事后没有价值的情况下添加验收测试套件。在继续进行进一步开发（大型重构工作或添加新功能）之前，您将构建一套回归验收测试来验证行为。

根据经验我会说如果你要完成这项任务，那么编写生产代码的关键开发人员最好远离编写验收测试（希望以Gherkin脚本的形式）;那些正在编写它们的人会回到最初的需求文档（如果有的话），并且肯定会与一些利益相关者合作。这将有助于确保您编写的验收测试更接近规范。

Answer 4

我喜欢观察到BDD-After只是编写验证的一种情况。我也很欣赏开发人员做BDD-After的评论错过了BDD-As-You-Go的其他一些好处。有一点似乎值得补充的是，在实现之前编写一个secenario / test然后进行测试传递也是一种验证测试本身是合理的。为已经有效的功能（BDD-After）编写通过测试可能会让开发人员想知道如果某个功能被破坏，他们的测试是否会“适当地失败”。