tdd - TDD 和 BDD 应该一起使用吗？

Question

我正在从 TDD 思维方式转变为 BDD。我知道使用 BDD 是为了确保满足软件的行为和业务目标。

令我困惑的是，如果我开始使用 BDD 代替 TDD，似乎我无法在如此低的级别进行测试。例如，在使用 TDD 思维方式编写测试时，我可能会测试属性是否已附加到范围:

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

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

在这样做时，另一个开发人员知道对作用域的分配是预期的并且需要将来使用，如果他们删除了分配或更改了默认值等，则可以为他们节省一些调试时间。

此示例未定义行为，因此不能被视为 BDD。当然，我可以重写测试描述以使其更加面向行为，例如“当页面加载时，设置属性供以后使用，以便用户可以这样做……”但这似乎太抽象了。

同时使用 TDD 和 BDD 是否已经完成？是否可以使用 BDD 来定义项目所有参与方(包括非技术)的行为，并专门为开发人员定义 TDD？

Answer 1

简短的回答，是的。

但是，BDD 和 TDD 之间的区别并不像您提到的那样，我想弄清楚“确保满足软件的行为和业务目标”的真正含义:)

BDD 先于、包围并超越了开发阶段。 BDD 不仅仅是一种语法，而不仅仅是从“测试”一词到“应该”一词的变化。 BDD 实际上是编写涉及端到端业务的软件的范式。 This page解释说:

BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

BDD 以 deliberate discovery 开头，一群人聚在一起，充实了一个 story using scenarios的细节。 .这群人通常由以下每个学科的 1 个以上组成:产品、开发和 QA - 也称为三个 friend 。此练习先于开发，非常擅长在您开始开发之前识别缺陷，并通过共享理解创建更好的规范。

一旦你有了一个好的故事和好的场景，你就可以使用 outside-in testing 来插入开发。方法:



这意味着您从验收测试开始(如果可以，请避免使用 UI)，并且当您将开发推进到系统中时，您将在集成和单元级别为诸如服务和域对象之类的东西使用 TDD。在这里你可以选择任何你喜欢的语法，你上面使用的“should”就可以了。

如果您使用的是 Javascript，我们创建了一个名为 Chimp 的开源工具。使由外向内测试的过程变得容易。

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

Specification by Example

Shallow Depth of Test