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 是第二代、由外而内、基于拉动、多利益相关者、多规模、高度自动化、敏捷的方法。它描述了一个与定义明确的输出交互的循环，从而交付重要的工作、经过测试的软件。

BDD 以deliberate discovery 开头，一群人聚在一起充实story using scenarios 的细节。这群人通常由以下每个学科中的 1 个以上组成：产品、开发和 QA - 也称为三个朋友。此练习在开发之前进行，非常适合在您开始开发之前识别缺陷，并通过共同理解创建更好的规范。

一旦你有一个好的故事和好的场景，你就可以使用outside-in testing 方法来推动开发：

这意味着您从验收测试开始（如果可以的话，避免使用 UI），并且当您将开发推进到系统中时，您会在集成和单元级别使用 TDD 来处理您的服务和域对象等内容。在这里你可以选择任何你喜欢的语法，你上面使用的“应该”就可以了。

如果您使用 Javascript，我们创建了一个名为 Chimp 的开源工具，以简化由外向内测试的过程。

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

• Specification by Example
• Shallow Depth of Test