Lun*_*ore 120
BDD"测试"存在于多个不同的粒度级别,一直到初始项目愿景.大多数人都知道这些场景.有些人记得BDD开始用"应该"这个词来代替JUnit的"测试" - 作为TDD的替代品.我把"测试"放在引号中的原因是因为BDD并不是真的要测试; 它专注于寻找缺乏理解或不匹配的地方.
由于这种关注,对话比BDD工具重要得多.
我要再说一遍.对话比BDD工具重要得多.
验收测试实际上并不强制要求对话,并且通常假设您正在编写的测试是正确的测试.在BDD中,我们假设我们不知道我们在做什么(可能不知道我们不知道).这就是为什么我们使用"Given,When,Then"之类的东西 - 这样我们就可以围绕场景和/或单元级示例进行对话.(这是大多数人都熟悉的两个级别 - 相当于验收测试和单元测试 - 但它的规模上升).
我们不称他们为"验收测试",因为你不能问商务人士"请帮助我进行验收测试".他们会以一种非常奇怪的,眯着眼睛的目光看着你,然后把你当成那个极客女孩.93%的人不想要那样.
试着"我想跟你谈谈......的情景".或者,"你能举个例子吗？" 这些都是好的.称他们为"验收测试"开始让人们认为你实际上正在进行测试,这意味着你知道自己在做什么,只是想确保你已经完成了.在这一点上,对话倾向于关注你能够多快地把错误的东西拿出来,而不是关于你弄错了事实的事实.
而你却搞错了.真的,老实说,你是.即使你认为自己不是,也只是因为你不理解二阶无知.你不知道你不知道,只要你找到了你不知道的地方就可以了.(你不会找到所有这些.不要让分类悖论让你夜不能寐.)
真正做到正确的唯一方法是事先了解所有要求,并且知道尝试时会发生什么.那就对了.这是瀑布.还记得加班吗？周末工作？七年没有你创造的东西进入生产？如果你想避免这种情况,你只有一次机会:假设你错了,对它进行一些谈话就不那么错了,然后接受你仍然错了,无论如何都要去做.过早写测试意味着你有更多的机会出错,现在变得更难,每个人都认为你是对的,而PM正在衡量你的速度,现在你又承诺错误了2周.而且 - 更糟糕的是 - 你要测试你了吗？
再来一次.对话比BDD工具重要得多.
请,请不要注意工具.这些工具只是一种捕获对话并确保它们在代码中播放的机制.场景不是会话的替代品,任何超过3 x 5的索引卡都可以替代需求.
话虽如此,如果你必须从一个工具开始,将Slim放在Fitnesse后面,以便它可以运行可爱的Given/When/Thens而不必弄乱Fit的桌子和固定装置.GivWenZen以Slim为基础,其中任何一个都是岩石.FitSharp与.NET领域的人相当.或者只是使用Cucumber或SpecFlow,或者敲一下可以完成多年工作的自定义DSL*.
透明度:*我写了那个.和JBehave的一点点.我希望我们称之为"不要专注于BDD-tools-Behave".我可能会大量参与BDD的其他部分.如果我能把这个消息拿出来,Dan North会给我一品脱,所以这不是完全公正的建议.
无论如何 - 已经进行了对话.这只是人.去谈谈.
我不知道是否有这样的事情,严格来说,作为"BDD测试".BDD是一种理念,它建议您如何与利益相关者进行最佳互动和协作,以完成复杂的项目.它不直接为编写测试的最佳方式制定任何处方.换句话说,您可能仍会在BDD哲学项目下进行所有常见的测试(包括验收测试).
当您听说"BDD框架"时,扬声器通常意味着一个框架,用于编写所有常见类型的测试但具有BDD扭曲.例如,在RSpec中,您仍然可以编写单元测试; 你只需要添加BDD风味.
| 归档时间： |
|
| 查看次数： |
12199 次 |
| 最近记录： |