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

简而言之,这与 分析 .

BDD用于“验收测试驱动的开发”,也就是说,用于了解正在测试的系统在特定的用户故事场景中是否按预期运行。

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

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

一个BDD场景说 什么 系统应该为用户故事做些什么 但不是如何 它做到了。

BDD是关于编写“可执行规范”或验收测试的。 black-box testing 根据定义, 从测试对象的外部透视图派生测试用例 .

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

行为驱动发展

行为=。在.. 发展——在……的建设中……

本例中的开发向我表明已经完成了分析,其中一个正在实现特定行为环境中的某个内容。

所以为了回答这个问题,我认为它在 设计 .

我认为从一个建筑POV BDD将是关于设计。我需要设计一个可以做一些事情的应用程序,稍后将在验收测试中使用。所以,从高层次的设计中,我想确保我是为各种行为需求而设计的,这样我就不会过度设计,并且限制重复。

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

BDD(或TDD)不是 关于 什么都行。这是一种支持分析的技术(在BDD的情况下,更多的是一种方法)。 和 设计(以及令人讨厌的小实现步骤)。您经常听到与TDD相关联的短语“红、绿、重构”,因此它适用于BDD:创建测试并查看它是否失败,通过更新代码库使测试通过,然后在保留通过的测试的同时将系统返工为改进的形式。

因此,当您创建测试时,BDD支持分析:您应该以测试或示例的形式描述所需的行为。它在运行测试时支持设计:您的设计决策不会无意中破坏所需的行为,并且可以由分析指导。但是它没有为你做任何分析或设计;你仍然需要思考。这是一种确保在分析和设计过程中,你不会自相矛盾的方法。

BDD和TDD甚至有一个非常不吉利的名字,因为它实际上并不包括它们的用途。

• 在开发周期中,您不希望为每个可能的角落案例编写测试,这是测试人员应该学习的内容。
• 你不需要回归,你要确保你在写代码,你需要清除这个迭代,所以你想要一个可重复的结果。
• 你不必一开始就做详细的设计,而是把你希望看到的一些需求写下来。

bdd/tdd如果你没有在你有一些描述你将要写的代码之前写一行代码,那么这两个代码中的任何一个都可以。这样你就会进入一个区域。
虽然没有证据表明bdd/tdd可以提高开发速度(很可能不会),但它将大大减少在发布已被证明的软件后您返回的问题数量。

BDD是TDD的一个演变,在这里TDD施加压力来测试BDD放松的所有东西,并且说您应该只测试类的公共行为,因为内部可能会发生变化。

BDD与设计和分析一样重要,但我不认为这就是你的问题,是吗?你想知道如何将故事转换成流程图和架构图?

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

在Scrum或类似的wise系统中,这非常有效,因为业务优先处理您的故事。您从顶部开始,为它编写一个规范/示例,然后尝试满足这个示例的要求,重复这个步骤,直到完成这个积压项,然后拿起下一个,然后重新开始。

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