我想知道，BDD只是在验收测试级别工作吗？如果没有，它在单元测试级别也能工作吗？BDD对单元测试有什么建议吗？
感谢
BDD只是定义功能领域规范的一种方式。这个想法是通过使用某种人类可读的语法来弥合技术人员和非技术人员之间的差距，并使用特定的例子来定义所需的行为，而不是抽象地谈论。因此，它是一种帮助人们共同工作并定义业务对新功能的需求的工具。这是BDD的主要观点。未进行测试。
然而，BDD中的定义对验收测试很有用，因为它们定义了商定的预期行为。因此，可以使用许多很棒的工具，如cucumber，来促进这些场景的自动化，从而减少测试时间。
关于使用BDD进行单元测试，使用BDD和非技术性描述的想法是帮助非技术人员参与进来。如果没有非技术人员参与单元测试的创建（我想这是最有可能的情况），那么为什么要麻烦它呢？技术人员可以阅读写得很好的单元测试。无论如何，您正在编写的单元测试都将来自BDD场景所描述的功能。
然而，如果您正在处理的内容中有一些技术细节难以描述，并且您的团队能够以BDD的方式轻松工作，那么一定要尝试非技术性语言和特定示例的方法。我只是不想在单元测试中使用这个示例的人类可读语言版本。
编辑：在阅读了xmojmr对您的问题的评论后，我完全可以看到使用BDD工具和语法使单元测试更可读/更容易规划的好处，但我认为这与一般的BDD截然不同，后者更多的是为了弥合沟通差距。
BDD实际上是从类级别开始的。JBehave的第一个化身是JUnit的替代品，它避免了"测试"这个词。直到后来，Dan North向当时正在学习如何编码的分析师Chris Matts解释了模拟对象后，系统级的东西才出现了。
如今，即使是单元测试框架也不坚持用"测试"这个词来启动测试方法，而且动态语言的框架基本上是从RSpec派生的，RSpec是JBehave早期功能到Ruby的移植。
所以，是的，在这个水平上做BDD是完全可能的。
当然，Alanichols说观众是不同的，是非技术性的，这是对的。
那么你为什么要做BDD呢？
正如Dan在第一个环节中所说，事实证明，谈论行为比谈论test更有用。在BDD中，我们只是避免使用测试这个词。我们更喜欢谈论的例子以及事情应该如何表现，而不是通过或失败。
通过围绕系统或类的期望行为进行对话，并提供该行为的示例，您可以比谈论测试时更容易地探索它。
然而，因为这是一个非技术性的受众，我发现在评论中加上"给定、何时、然后"就足够了。你可以在这里看到一个例子。您不需要一个明确的BDD工具。
如果你找不到另一个开发者来谈论这种行为，我建议你找一只橡皮鸭。