TDD和BDD应该一起使用吗？

Question

9

我来自TDD的思维方式，现在转向BDD。我知道使用BDD是为了确保软件行为和业务目标得到满足。

让我困惑的是，如果我开始使用BDD代替TDD，似乎我不能在如此低的级别进行测试。例如，在以TDD思维方式编写测试时，我可能会测试属性是否已附加到作用域中：

it('should attach properties to scope', function () {

  expect(MainCtrl.items.length).toEqual(1);
});

在做这个的时候，另一个开发者知道作用域分配是预期和未来使用所需的，这样如果他们删除了分配或更改了默认值等，就可以节省一些调试时间。

这个例子没有定义行为，因此不能被视为BDD。当然，我可以重新编写测试描述，使其更加面向行为，比如，“当页面加载时，设置属性以供稍后使用，以便用户可以做某些事情......”，但这似乎太抽象了。

同时使用TDD和BDD是一种惯用做法吗？是否可以通过使用BDD来定义参与项目的所有人（包括非技术人员）的行为，而专门使用TDD来供开发人员使用？

- Ian Lunn

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Xolv.io · Accepted Answer

简短回答，是的。

然而，BDD和TDD之间的区别不是你所提到的那样，我想澄清一下"确保软件的行为和业务目标得到满足"实际上意味着什么 :)

BDD先于开发阶段，包含并超越了开发阶段。BDD远不止是语法，也不仅仅是从"测试"这个词变成"应该"这个词。BDD实际上是一种编写涉及端到端业务的软件的范式。此页面解释了：

BDD是第二代、自外向内、拉动式、多利益相关者、多规模、高自动化、敏捷方法论。它描述了一系列有明确定义输出的交互循环，最终交付重要的工作、经过测试的软件。

BDD始于深思熟虑的发现，在那里一组人聚在一起，使用场景来细化故事的细节。这个小组通常由以下各个领域的1+人员组成：产品、开发和QA-也称为三个朋友。这项练习在开发之前进行，非常擅长在开始开发之前识别缺陷，并通过共享理解创建更好的规范。

一旦你有了一个好的故事和好的场景，就可以使用从外到内的测试方法来推动开发：

这意味着您从验收测试开始（如果可能，避免使用UI），随着开发进入系统，您在服务和领域对象等集成和单元级别上采用TDD。在这里，您可以选择任何语法，使用“should”就可以了。

如果您正在使用JavaScript，我们创建了一个名为Chimp的开源工具，使外部测试过程变得容易。

最后，我建议您查看以下链接：