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

Question

我读到的关于BDD和应该如何改进TDD的文章越多，对我来说就越混乱。我找到了专家的名言，他们说这是关于设计的，但也有来自其他专家的，他们说这是关于分析的。

我目前的看法是：

1)分析: BDD

来自维基百科

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

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

( 2)设计:例如使用CRC卡的可共振驱动设计。

3)代码:编写设计代码，可选地使用测试(就像他们所说的TDD做错了什么，我也觉得这很有用)

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

Answer 1

简而言之，这与Analysis有关。

BDD用于“接受测试驱动的开发”--即了解被测试的系统在特定用户故事场景中的行为是否符合预期。

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

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

一个BDD场景告诉系统对用户故事应该做什么，而不是它是如何做的。

Answer 2

BDD是关于编写“可执行规范”或验收测试。根据定义，黑匣子测试采用测试对象的外部透视图来派生测试用例。

所以BDD不可能是关于设计的，BDD是关于测试特性/故事/场景的，BDD更接近于分析。

Answer 3

BDD -行为驱动的开发

..in =..的上下文。开发- ...in的建设。

在这种情况下，事态发展向我表明，分析已经完成，其中一项是在特定行为的背景下实施的。

因此，为了回答这个问题，我在设计中解释了这个问题。