tdd - 行为驱动开发是否只是验收测试软件？

Question

我想知道，BDD 是否只在验收测试级别工作？如果不是，它是否也适用于单元测试级别？BDD 对单元测试有什么建议吗？

谢谢你

Answer 1

BDD 只是定义功能领域规范的一种方式。这个想法是通过使用某种人类可读的语法来弥合技术人员和非技术人员之间的差距，并使用特定示例来定义所需的行为，而不是抽象地谈论。因此，它是帮助人们一起工作并定义业务对新功能的需求的工具。这是 BDD 的要点。不测试。

然而，来自 BDD 的定义对于验收测试很有用，因为它们定义了商定的预期行为。因此，有许多很棒的工具（例如 cucumber）可用于促进这些场景的自动化，从而减少您的测试时间。

关于将 BDD 用于单元测试之类的事情，使用 BDD 和非技术描述的想法是帮助非技术人员参与进来。如果没有非技术人员参与创建单元测试（我猜这是最有可能的情况），那么为什么要打扰它呢？技术人员可以阅读正确编写的单元测试，就好了。无论如何，您正在编写的单元测试将来自您的 BDD 场景所描述的功能。

但是，如果您正在处理的某些技术细节难以描述，并且您的团队能够以 BDD 方式工作，那么一定要尝试使用非技术语言和具体示例方法。我只是不会在您的单元测试中使用该示例的人类可读语言版本。

编辑：在阅读 xmojmr 对您的问题的评论后，我绝对可以看到使用 BDD 工具和语法使您的单元测试更具可读性/更容易计划的好处，但我认为这与一般 BDD 完全不同，后者更多的是弥合沟通鸿沟。

Answer 2

BDD 实际上是从班级级别开始的。JBehave 的第一个化身是 JUnit 的替代品，它避免了“测试”这个词。直到后来，在 Dan North向当时正在学习如何编码的分析师Chris Matts 解释了模拟对象之后，系统级的东西才出现。

如今，即使是单元测试框架也不会坚持用“test”这个词来开始你的测试方法，而动态语言的框架在很大程度上是从 RSpec 派生的，无论如何，RSpec 是JBehave对 Ruby 的早期功能的一个端口。

所以，是的，完全有可能在那个级别上做 BDD。

当然，alannichols说观众是不同的，是非技术性的，这是正确的。

那么你为什么要做BDD呢？

正如 Dan 在第一个链接中所说，事实证明，谈论行为比谈论测试更有用。在 BDD 中，我们只是避免使用test一词。我们更喜欢谈论例子和事情应该如何表现，而不是通过或失败。

通过围绕系统或类的期望行为进行对话，并提供该行为的示例，您可以比讨论测试更容易地探索它。

然而，因为它是非技术观众，我发现在评论中放置“给定，何时，然后”就足够了。你可以在这里看到一个例子。您不需要显式的 BDD 工具。

如果你找不到另一个开发者来谈论这个行为，我建议你找一只橡皮鸭。