testing - BDD可以“之后”完成吗？

Question

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

开发后的 BDD 不是 BDD，它是一个验证而不是规范的案例。

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

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

Answer 4

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