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

Question

我对 BDD 以及如何改进 TDD 的了解越多，我就越感到困惑。我发现专家的引言说这是关于设计的，但也有其他专家说这是关于分析的。

我目前看到的方式是这样的：

1）分析：BDD

从 维基百科

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

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

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

3）代码：对设计进行编码，可以选择使用测试（就像他们所说的 TDD 做错了一样，我也发现这很有用）

我的看法有错吗？我现在很难透过树木看到森林。

Answer 1

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

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

当我与Jbehave合作时，我们在用户故事级别使用它并且仍然使用“常规”级别。 TDD用于处理各个对象之间以及子系统之间的协作。

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

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

。

Answer 2

BDD是关于编写“可执行规范”的。或验收测试又名黑盒测试，根据定义，采取测试对象的外部视角来导出测试用例。

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

Answer 3

BDD - 行为驱动的发展

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

BDD 和 TDD 甚至有一个非常不吉利的名字，因为它实际上并没有涵盖它们的用途。

• 您不想在开发周期中为每个可能的极端情况编写测试，而这是测试人员应该学习的内容。
• 您不需要回归，并且希望确保编写清除此迭代所需的代码，以便获得可重复的结果
• 您不必在一开始就进行详细设计，而是记下一些您希望这次完成的要求。

如果您在有一段代码描述您要编写的代码之前不编写一行代码，则 BDD/TDD 两者中的任何一个都可以。这样做你就会进入一个区域。
虽然没有证据表明 BDD/TDD 会提高您的开发速度（很可能不会），但它会大大减少您在发布已被证明的软件后遇到的问题数量。

BDD 是 TDD 的演变，其中 TDD 施加了测试所有内容的压力，BDD 放松了这一点，并表示您应该只测试类的公共行为，因为内部可能会发生变化。

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

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

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

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