BDD可以“之后”完成吗？答案

【问题标题】：Can BDD be done "after"?BDD可以“之后”完成吗？
【发布时间】：2012-04-20 06:11:04
【问题描述】：

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

如果你把BDD写在“之后”，而且不是BDD，那它叫什么？

【问题讨论】：

【解决方案1】：

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

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

【讨论】：

如果不是BDD，那它叫什么？
通过行为/规范测试进行常规开发。 :P
您仍然可以通过手动进行对话和测试来进行 BDD。当然，自动化非常有用，但远没有对话重要。 BDD 只是旨在帮助开发人员进行这些对话并将语言带入代码中。请不要专注于自动化！

【解决方案2】：

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

有些人称 BDD 是因为 TDD 做得正确，或者按照预期的方式。此外，您可以说 BDD 是领域驱动开发 (DDD) 和 TDD 的混合体。

【讨论】：

【解决方案3】：

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

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

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

【讨论】：

【解决方案4】：

我喜欢 BDD-After 只是一个编写验证的例子。我也很感激开发 BDD-After 的开发人员错过了 BDD-As-You-Go 的其他一些好处。似乎值得补充的一点是，在实现之前编写一个场景/测试然后让测试通过也是一种验证测试本身是否合理的类型。为已经有效的功能（BDD-After）编写通过测试可能会让开发人员想知道如果功能被破坏，他们的测试是否会“适当地失败”。

【讨论】：