我是从TDD心态进入BDD.我知道使用BDD的重点是确保满足软件的行为和业务目标.
令我困惑的是,如果我开始使用BDD代替TDD,似乎我无法在如此低的水平上进行测试.例如,在使用TDD思维模式编写测试时,我可能会测试属性是否已附加到范围:
it('should attach properties to scope', function () {
expect(MainCtrl.items.length).toEqual(1);
});
Run Code Online (Sandbox Code Playgroud)
在这样做时,另一个开发人员知道预期范围的分配是预期的,并且需要将来使用,如果他们已经删除了分配或更改了默认值等,则保留一些调试.
此示例未定义行为,因此不能将其视为BDD.当然,我可以重写测试描述,使其更加面向行为,例如,"当页面加载时,设置属性供以后使用,以便用户可以这样做......"但这似乎太抽象了.
同时使用TDD和BDD是否是完成的事情?BDD是否可用于为项目参与者(包括非技术人员)和TDD专门为开发人员定义行为?
简短的回答,是的.
然而,BDD和TDD之间的区别并不像你提到的那样,我想清楚"确保软件的行为和业务目标得到满足"真正意味着:)
BDD先于,包围并超越了开发阶段.BDD不仅仅是一种语法,而不仅仅是从"测试"一词到"应该"这个词的变化.BDD实际上是编写涉及端到端业务的软件的范例.本页解释说:
BDD是第二代,从外到内,基于拉动,多利益相关方,多规模,高自动化,敏捷的方法.它描述了与明确定义的输出相互作用的循环,从而提供了重要的可运行的,经过测试的软件.
BDD从故意发现开始,一群人聚集在一起,使用场景充实故事的细节.这群人通常由以下各个学科中的1个以上组成:产品,开发和质量保证 - 也称为三个朋友.此练习在开发之前进行,并且在您开始开发之前非常擅长识别缺陷,并通过共享理解创建更好的规范.
一旦你有一个好的故事情节,你就可以使用一种从外到底的测试方法来推动开发:
这意味着您从验收测试开始(如果可以,请避免使用UI),并且当您将开发推入系统时,您将在集成和单元级别使用TDD来处理服务和域对象等事务.在这里,您可以选择任何您喜欢的语法,以及上面使用"should"的内容就可以了.
如果你正在使用Javascript,我们创建了一个名为Chimp的开源工具,使外部测试过程变得简单.
最后,我建议你看看以下链接: