BDD会替换TDD，还是一起使用？我一直在读BDD应该只测试用户可以看到的东西。如果是这种情况，这是否意味着需要将TDD用于用户无法看到的服务方法？
答案 0 :(得分：6)
BDD是TDD和ATDD的替代品（并从中衍生出来）。
BDD的第一个工具JBehave实际上是作为单元测试框架JUnit的替代品而开始的。其意图是，它允许您描述您（尚未写入）系统的行为并提供示例，而不使用单词＆＃34; test＆＃34;，因为它真的在那个阶段进行了分析，而不是测试。那个词，＆＃34; test＆＃34;，引起了各种混乱！
区别在于示例和行为和规范都是问题空间语言，而单词 test 是解决方案空间。它倾向于让人们认为他们理解问题，并且正在测试解决方案，这是一个问题，如果他们真的没有！
事实证明，避免单词 test 可以帮助人们更全面地探索问题。您可以在Dan North's original article中了解相关信息。
Dan在2003/4期间正在探索BDD，他向当时正在担任业务分析师的Chris Matts解释说。克里斯说，＆＃34;但那就像分析一样！＆＃34;因此，他们开始探索克里斯如何对整个系统进行分析，以及如何运作的例子，克里斯意识到它不仅仅是关于行为和结果，而是关于行为和结果在一个环境中。这形成了整个＆＃34;给定，何时，然后＆＃34;我们现在知道的语法（那时候它还没有被称为Gherkin，因为Cucumber并不存在）。
所以Dan开始在单元之上编写一个场景运行框架 - ＆＃34;测试＆＃34;工具，然后将其移植到Ruby作为RBehave，然后变成纯文本并成为Cucumber。那时，BDD成为ATDD的替代品（当时通常使用单元测试工具以令人难以置信的程序脚本完成）。
您是否在低级别使用JUnit，NUnit或任何其他类型的单元测试框架并不重要。如果您正在考虑行为示例，并通过这些示例进行讨论，那么您就是在做BDD。编写示例很有用，自动化它们也很有用，这就是为什么有像JBehave和Cucumber这样的BDD工具在系统级工作的原因。
我们并不需要更低级别的特定BDD工具，因为开发人员和测试人员很容易映射＆＃34;测试＆＃34;到＆＃34;示例＆＃34;或＆＃34;应该＆＃34;不用担心。
不同之处在于人们可以轻松地进行对话，而不使用＆＃34; test＆＃34;。
当您为某个班级编写BDD时，＆＃34;用户＆＃34;那个班级通常是另一个班级。因此，以基于系统用户可以看到的内容编写方案的相同方式，您可以根据另一个类可以看到的内容编写较低级别的示例。从BDD出来的测试是一个非常好的副产品，但对话是最重要的方面，即使这个对话必须与橡皮鸭发生。
答案 1 :(得分：0)
BDD并没有取代TDD，我认为它补充了BDD。
这一切都取决于问题，企业是否会关心这个问题？
您希望使用正确的工具来完成工作。也就是说，有些东西非常适合BDD，而其他一些东西更适合TDD。如果操作正确，BDD和TDD之间的界限非常模糊。如果它存在。
我写了一篇博客文章，讨论了一个名为“测试冰山”的概念，http://www.thinkcode.se/blog/2016/07/25/the-right-tool-for-the-job
它可能会为你的问题分享一些额外的亮点。
我同意@Lunivore认为，与理解你从对话中得到的问题相比，工具的选择并不重要。