TDD 和 BDD 应该结合使用吗？
Should TDD and BDD be used in conjunction?
我正在从 TDD 思维转变为 BDD。我理解使用 BDD 是为了专注于确保软件的行为和业务目标得到满足。
让我感到困惑的是，如果我开始使用 BDD 代替 TDD，那么我似乎无法在如此低的级别上进行测试。例如，当使用 TDD 思维方式编写测试时，我可能会测试属性是否已附加到范围：
it('should attach properties to scope', function () {
expect(MainCtrl.items.length).toEqual(1);
});
在执行此操作时，另一位开发人员知道对范围的分配是预期的并且是将来使用所必需的，如果他们删除了分配或更改了默认值等，则可以为他们节省一些调试时间。
此示例未定义行为，因此不能视为 BDD。当然，我可以重写测试描述，使其更面向行为，例如，"when the page loads, setup properties for later use so the user can do so and so..." 但这似乎太抽象了。
同时使用 TDD 和 BDD 是一件既定的事情吗？ BDD 是否可用于为项目中涉及的所有各方（包括非技术人员）和 TDD 专门为开发人员定义行为？
简答，是的。
但是，BDD 和 TDD 之间的区别并不像您提到的那样，我想弄清楚 "ensuring the behaviours and business goals of software are being met" 的真正含义:)
BDD 先于、包含并超越开发阶段。 BDD 不仅仅是一种语法，而不仅仅是从单词 "test" 到单词 "should" 的变化。 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, where a group of people get together and flesh out the details of a story using scenarios 开头。这群人通常由以下每个学科中的 1+ 人组成：产品、开发和 QA - 也称为三个朋友。此练习先于开发，非常擅长在开始开发之前识别缺陷，并通过共同理解创建更好的规范。
一旦有了好的故事和好的场景，就可以使用 outside-in testing 方法推动开发：
这意味着您从验收测试开始（如果可以，请避免 UI），并且在将开发驱动到系统中时，您在集成和单元级别使用 TDD 来处理服务和域对象。在这里你可以选择任何你喜欢的语法，你上面用 "should" 的语法就可以了。
如果您正在使用 Javascript，我们创建了一个名为 Chimp 的开源工具来简化由外而内的测试过程。
最后推荐大家看看以下链接：
我正在从 TDD 思维转变为 BDD。我理解使用 BDD 是为了专注于确保软件的行为和业务目标得到满足。
让我感到困惑的是，如果我开始使用 BDD 代替 TDD，那么我似乎无法在如此低的级别上进行测试。例如，当使用 TDD 思维方式编写测试时，我可能会测试属性是否已附加到范围：
it('should attach properties to scope', function () {
expect(MainCtrl.items.length).toEqual(1);
});
在执行此操作时，另一位开发人员知道对范围的分配是预期的并且是将来使用所必需的，如果他们删除了分配或更改了默认值等，则可以为他们节省一些调试时间。
此示例未定义行为，因此不能视为 BDD。当然，我可以重写测试描述，使其更面向行为，例如，"when the page loads, setup properties for later use so the user can do so and so..." 但这似乎太抽象了。
同时使用 TDD 和 BDD 是一件既定的事情吗？ BDD 是否可用于为项目中涉及的所有各方（包括非技术人员）和 TDD 专门为开发人员定义行为？
简答，是的。
但是，BDD 和 TDD 之间的区别并不像您提到的那样，我想弄清楚 "ensuring the behaviours and business goals of software are being met" 的真正含义:)
BDD 先于、包含并超越开发阶段。 BDD 不仅仅是一种语法，而不仅仅是从单词 "test" 到单词 "should" 的变化。 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, where a group of people get together and flesh out the details of a story using scenarios 开头。这群人通常由以下每个学科中的 1+ 人组成：产品、开发和 QA - 也称为三个朋友。此练习先于开发，非常擅长在开始开发之前识别缺陷，并通过共同理解创建更好的规范。
一旦有了好的故事和好的场景，就可以使用 outside-in testing 方法推动开发：
这意味着您从验收测试开始（如果可以，请避免 UI），并且在将开发驱动到系统中时，您在集成和单元级别使用 TDD 来处理服务和域对象。在这里你可以选择任何你喜欢的语法，你上面用 "should" 的语法就可以了。
如果您正在使用 Javascript，我们创建了一个名为 Chimp 的开源工具来简化由外而内的测试过程。
最后推荐大家看看以下链接：