BDD会替换TDD,还是一起使用？我一直在读BDD应该只测试用户可以看到的东西.如果是这种情况,那是否意味着需要将TDD用于用户看不到的服务方法？
BDD是TDD和ATDD(并从中衍生出来)的替代品.
BDD的第一个工具JBehave实际上是作为单元测试框架JUnit的替代品而开始的.目的是它允许你描述你的(尚未编写的)系统的行为并提供示例,而不使用"test"这个词,因为在那个阶段它实际上是分析而不是测试.这个词,"测试",引起各种混乱!
不同之处在于示例和行为以及规范都是问题空间语言,而单词test是解决方案空间.它倾向于让人们认为他们理解问题,并且正在测试解决方案,这是一个问题,如果他们真的没有!
事实证明,避免单词测试可以帮助人们更充分地探索问题.您可以在Dan North的原始文章中了解这一点.
虽然Dan在2003/4期间正在探索BDD,但他向当时正在担任业务分析师的Chris Matts解释过.克里斯说,"但这就像分析一样!" 因此,他们开始探索如何克里斯做了全系统的分析,和这样的例子是如何工作的,以及克里斯意识到这不仅仅是行为和结果,它是关于行为和结果的情况下.这形成了我们现在知道的整个"Given,When,Then"语法(当时因为Cucumber不存在而没有被称为Gherkin).
因此,Dan开始在单元"测试"工具之上编写一个场景运行框架,然后将其作为RBehave移植到Ruby,然后将其转换为纯文本并成为Cucumber.那时,BDD成为ATDD的替代品(当时通常使用单元测试工具完成程序脚本).
无论您是在低级别使用JUnit,NUnit还是任何其他类型的单元测试框架,这都无关紧要.如果您正在考虑行为示例,并通过这些示例进行讨论,那么您正在进行BDD.编写示例是很有用的,自动化它们也很有用,这就是为什么有像JBehave和Cucumber这样的BDD工具在系统级工作的原因.
我们并不需要更低级别的特定BDD工具,因为开发人员和测试人员很容易将"测试"映射到"示例"或"应该"而不用担心它.
不同之处在于人们可以轻松地进行对话,而不使用"测试"一词.
当你为一个类编写BDD时,该类的"用户"通常是另一个类.因此,以基于系统用户可以看到的内容编写方案的相同方式,您可以根据另一个类可以看到的内容编写较低级别的示例.BDD出来的测试是一个非常好的副产品,但谈话是最重要的方面,即使谈话必须与橡皮鸭发生.