TDD和BDD应该结合使用吗?

Ian*_*unn 4 tdd bdd

我是从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专门为开发人员定义行为?

Xol*_*.io 5

简短的回答,是的.

然而,BDD和TDD之间的区别并不像你提到的那样,我想清楚"确保软件的行为和业务目标得到满足"真正意味着:)

BDD先于,包围并超越了开发阶段.BDD不仅仅是一种语法,而不仅仅是从"测试"一词到"应该"这个词的变化.BDD实际上是编写涉及端到端业务的软件的范例.本页解释说:

BDD是第二代,从外到内,基于拉动,多利益相关方,多规模,高自动化,敏捷的方法.它描述了与明确定义的输出相互作用的循环,从而提供了重要的可运行的,经过测试的软件.

BDD从故意发现开始,一群人聚集在一起,使用场景充实故事的细节.这群人通常由以下各个学科中的1个以上组成:产品,开发和质量保证 - 也称为三个朋友.此练习在开发之前进行,并且在您开始开发之前非常擅长识别缺陷,并通过共享理解创建更好的规范.

一旦你有一个好的故事情节,你就可以使用一种从外到底的测试方法来推动开发:

从外到内的测试

这意味着您从验收测试开始(如果可以,请避免使用UI),并且当您将开发推入系统时,您将在集成和单元级别使用TDD来处理服务和域对象等事务.在这里,您可以选择任何您喜欢的语法,以及上面使用"should"的内容就可以了.

如果你正在使用Javascript,我们创建了一个名为Chimp的开源工具,使外部测试过程变得简单.

最后,我建议你看看以下链接:

  • 谢谢@LuisVasconcellos。由外而内(根据我的经验)最好在域级别完成。您想要确保该域正常工作。看看六边形架构或干净的架构方法。这里有一个链接可以解释我的意思:https://khalilstemmler.com/articles/domain-driven-design-intro/ 当您使用 UI 进行测试时,您绘制的测试边界太大并且作为一个结果你会得到域泄漏。核心业务域和 UI 域之间存在差异。这是关于此的另一个链接:) https://dannorth.net/2011/01/31/whose-domain-is-it-anyway/ (2认同)