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