我想知道，BDD 是否只在验收测试级别工作？如果不是，它是否也适用于单元测试级别？ BDD 对单元测试有什么建议吗？
谢谢
【问题讨论】：
BDD 只是定义功能领域规范的一种方式。这个想法是通过使用某种人类可读的语法来弥合技术人员和非技术人员之间的差距，并使用特定示例来定义所需的行为，而不是抽象地谈论。因此，它是帮助人们一起工作并定义业务对新功能的需求的工具。这是 BDD 的要点。没有测试。
但是，来自 BDD 的定义对于验收测试很有用，因为它们定义了商定的预期行为。因此，有许多很棒的工具（例如 cucumber）可用于促进这些场景的自动化，从而减少您的测试时间。
关于将 BDD 用于单元测试之类的事情，使用 BDD 和非技术描述的想法是帮助非技术人员参与进来。如果没有非技术人员参与创建您的单元测试（我猜这是最可能的情况），那么为什么要打扰它呢？技术人员可以阅读正确编写的单元测试，就好了。无论如何，您正在编写的单元测试将来自您的 BDD 场景所描述的功能。
但是，如果您正在处理的某些技术细节难以描述，并且您的团队能够以 BDD 方式工作，那么请务必尝试使用非技术语言和具体示例方法.我只是不会在您的单元测试中使用该示例的人类可读语言版本。
编辑：在阅读 xmojmr 对您的问题的评论后，我绝对可以看到使用 BDD 工具和语法使您的单元测试更具可读性/更容易计划的好处，但我认为这与 BDD 完全不同一般而言，这更多是为了弥合沟通鸿沟。
【讨论】：
BDD 实际上是started at the class level。 JBehave 的第一个化身是 JUnit 的替代品，它避免了“测试”这个词。直到后来，系统级的东西才出现在 Dan North explained mock objects to Chris Matts 之后，当时正在学习如何编码的分析师。
如今，即使是单元测试框架也不会坚持以“测试”一词开始测试方法，而动态语言的框架几乎都源自 RSpec，无论如何，RSpec 是 a port of JBehave's early functionality 到 Ruby。
所以，是的，完全有可能在那个级别进行 BDD。
当然，alannichols 说受众不同，非技术性的说法是对的。
那你为什么要做 BDD？
正如 Dan 在第一个链接中所说，事实证明，谈论 行为 比谈论 测试 更有用。在 BDD 中，我们只是避免使用 test 这个词。我们更喜欢谈论示例以及事情应该如何表现，而不是通过或失败。
通过围绕系统或类的期望行为进行对话，并提供该行为的示例，您可以比讨论测试更轻松地探索它。
但是，由于它是非技术受众，我发现将“给定，何时，然后”放在 cmets 中就足够了。你可以看到an example here。您不需要显式的 BDD 工具。
如果你找不到其他开发者来谈论这种行为，我建议你find a rubber duck。
【讨论】：