行为驱动开发是关于设计还是分析？

Question

我读到的关于BDD的内容越多以及它应该如何改进TDD，这一切对我来说都更加混乱。我发现专家的引言说它是关于设计的，还有来自其他专家的引用，这些专家说它是关于分析的。

我目前看到的方式是：

1）分析：BDD

来自wikipedia

  

面向对象分析的结果   是系统的描述   功能上要求做的，在   形式的概念模型。

因此在BDD之后我们有了要求（故事和场景）。但我不确定概念模型部分。

2）设计：例如使用CRC卡的resonsibility驱动设计等工具

3）代码：编码设计，可选择使用测试（就像他们所说的关于TDD做错了，我也觉得有用）

我怎么看错了？我现在很难看到森林穿过树林。

Answer 1

简而言之，这与分析有关。

BDD用于“验收测试驱动开发” - 即用于了解被测系统是否符合特定用户故事情景的预期。

当我与Jbehave合作时，我们在用户故事层使用它，并且仍然使用“常规”TDD来处理单个对象之间和子系统之间的协作。

通常，业务系统使用BDD方案来描述业务域行为，而不是测试系统内的微小实现细节。您希望BDD场景适用于域专家的抽象级别。这些场景对领域专家来说没有多大意义，如果他们描述了实施的每一个细节，那么这些场景就会非常脆弱。

BDD场景说 系统应该为用户故事而不是做什么

。

Answer 2

BDD是关于编写“可执行规范”或接受测试a.k.a. black-box testing，根据定义，采用测试对象的外部视角来派生测试用例。

所以BDD不能关于设计，BDD是关于测试功能/故事/ scenarii，BDD更接近分析。

Answer 3

BDD - 行为驱动的发展

行为= ..在......的背景下 发展 - ......在......的建设中。

在这种情况下的发展向我表明，分析已经完成，而且正在实施某种特定行为背景下的内容。

所以为了回答这个问题，我在设计中相信了它。

Answer 4

我认为从一个架构POV BDD将是关于设计。我需要设计一个可以做某事的应用程序，稍后将用于验收测试。所以，从高级设计我想确定我正在设计各种行为要求，这样我就不会过度设计，并限制重复。

它有助于确保我们可能不需要重新设计，因为用户有更多时间考虑他们实际想要看到的内容，应用程序将如何执行。

Answer 5

BDD（或TDD）不是关于任何事情。这是一种技术（在BDD的情况下，更多的方法）支持分析和设计（以及那个讨厌的小实现步骤）。您经常听到与TDD相关联的短语“red，green，refactor”，因此它适用于BDD：创建测试并看到它失败，通过更新代码库使测试通过，然后将系统重新编写为改进形式你保留了通过测试。

因此，BDD在您创建测试时支持分析：您应该以测试或示例的形式描述所需的行为。它在运行测试时支持设计：防止您的设计决策无意中破坏所需的行为，并且可以通过分析来指导。但它不会为您做任何分析或设计;你仍然需要思考。这是一种确保在分析和设计步骤中不会与自己发生冲突的方法。

Answer 6

BDD和TDD更具有非常不吉利的名称，因为它实际上并没有涵盖它们的用途。

• 您不希望在开发周期中针对每个可能的角落情况编写测试，这是测试人员应该选择的。
• 您不想要回归，并且您希望确保编写清除此迭代所需的代码，以便获得可重复的结果
• 你不必在开始时做详细的设计，而是记下一些你希望这次看完的要求。

BDD / TDD如果你没有编写一行代码，而你有一些代码描述了你要编写的代码，那么2中的任何一个都没问题。这样你就可以进入一个区域 虽然没有证据表明BDD / TDD会提高您的开发速度（很可能不会），但它会大大减少您在发布已经过验证的软件后获得的问题数量。

BDD是TDD的演变，其中TDD施加压力来测试BDD放松的一切，并且说你应该只测试你的类的公共行为，因为内部可能会改变。

BDD与设计和分析一样多，但我认为这不是你的问题吗？您想知道如何将故事翻译成流程图和架构图吗？

因为我从你的问题中得到的结论是你先做了一个大设计，然后尝试编写出来。这不适用于BDD，因为在满足您应该以零碎方式编写的故事的同时，您可以自动获取代码和架构。它被称为紧急设计，因此没有庞大的规划阶段。

在SCRUM或类似的系统中，这非常有效，因为业务优先考虑您的故事。您从顶部开始并为其编写规范/示例，然后尝试满足重复此示例的示例，直到您完成此积压项目，然后选择下一个项目并重新开始。

我希望这能回答你的问题..如果不是你，你需要澄清一点，因为这是一个大问题。简而言之，BDD纯粹是一个开发人员工具，不适用于架构师，BA，......测试人员可能会使用BDD工具，但我希望这不是他们用来测试应用程序的唯一工具。