BDD是否可扩展到大中型项目?


22

在您阅读的有关BDD(行为驱动开发)的每个网站中,您都可以找到一个非常简单的好例子,向您展示定义需求的显而易见和容易。但是,尝试在大型产品(而不是计算器示例)中实施此过程,向我展示了事情可能变得(或将变得)非常复杂且难以理解。特别是在稍后更改请求意味着为此需要进行大量的工作来更正集成测试。

所以我想知道,BDD真的值得吗?它是否解决了其他技术无法解决的问题!


太糟糕了,考虑到BDD最近越来越流行,我认为这个问题具有建设性。
DD

1
如果有人有足够的代表可以建议重新开放,那就太好了。
DD

我会重新开放,但您已经接受了第一个答案……
MattDavey

1
我接受了,因为它是封闭的,所以我知道不可能再有其他答案了,但是我真的对此有更多经验报告感兴趣,我现在就不接受它
DD

2
好的:)我想您也应该稍微编辑一下问题。我认为您的问题是BDD在大型项目中的可伸缩性。“ BDD真的那么好”是主观的,“ BDD是否可以很好地扩展到大型项目”则更具客观性。
MattDavey

Answers:


6

我认为最好的资源之一BDD规范用例的书。它介绍了许多有关如何组织BDD测试以及应该如何编写它们的内容,以便在需求变化时不会造成太多的返工。

如果您的测试变得复杂或过于复杂,则可能是您做错了。BDD和TDD相同。编写好的测试很困难,而且要花几个月的时间才能学会。


3
TDD是不一样的,测试预定义的单元永远不会变得如此复杂,除非您有太大的单元,这就是代码的味道,但是集成测试应该测试一个以上单元之间的交互,即整个功能,这会使它的复杂性增加与要求成线性关系,但仍然不能将其拆分成较小的部分,因为如果完成,将不再进行集成测试。
DD

您可以附加一些复杂的BDD测试,我可以看到可以做些什么来简化它们。
2013年

这不是那么容易,我在这里用的不是英语,我不得不翻译它们,如果生病了,我可以轻松将其翻译成英语,我可能会附上它,但是后面的代码仍然是一个问题,那就是太大而无法在一个帖子中显示。
DD

为什么这被否决?我提供了很多资源,可以帮助OP解决他的问题。
2013年

那不是我,我会给+1以补偿,但是我只能在14个小时内做到这一点,因为我今天用了我所有的30票。
DD

5

可能会认识到BDD的重点是对话。BDD实际上是一种分析工具,它恰好可以提供一些回归测试,作为一个很好的副产品。

我已经在各种级别的对话中使用了场景。从确定不同的利益相关者以查看发布是否很可能被接受,到确定模块或类的行为方式

我可以建议一些提示和技巧来简化此过程。

如果您以前从未做过,它将改变。

对于域或业务而言,任何新事物都可能发生变化。如果您正在讨论这些场景,对其进行质疑,并且业务人员说:“哦,我不确定,” 您可能会意识到自己正处在这个空间中。这是停止尝试执行BDD并添加一些内容以获取更快的反馈,以帮助企业确定所需内容的好兆头。一旦想法稳定下来,就可以回顾场景。

所有项目在某些方面都是新的,否则您就不会这样做。

如果您以前做过,那很无聊。

除了新的,与众不同的方面之外,项目通常还具有一些商品化方面,与已经完成的方面类似。例如,如果我要生产一部新手机,它仍然需要拨打电话。“打个电话”是一个众所周知的场景,我们无需讨论。同样,“登录”甚至“用户注册”之类的东西都很无聊。

尽可能在这些库中使用库,然后就不必围绕它们编写方案。另外,请先进行其他操作-已经有一个已登录的用户,然后计算出他要登录的内容。这些区域不太可能更改,因此无论如何您都可以摆脱手动测试。

如果有人以前做过,那么通过场景进行交谈会有所帮助。

在我们有特定于域的需求,某些人相对理解的东西和真正的不确定性主要围绕范围而不是系统的实际行为之间,存在一些差异。

通过场景进行交谈可以帮助开发团队发现行为,利用专家的知识,并确保捕获已知的有价值的行为。

这是BDD最有效的地方。我的技巧是在功能文件(或Wiki,如果您不进行自动化)的顶部编写最有趣的方案,并删除所有重复或易于推断的方案。

尽可能使用方案作为应用程序工作方式的示例。例如,如果要显示验证的工作原理,请显示几个应用程序如何帮助用户填写表格的示例。使用单元测试来检查验证是否严格,这更容易维护和运行。

进一步阅读

如果您对此感兴趣,这里有一些我写的东西可能会有所帮助。

BDD中的大

针对开发人员的Cynefin,将更详细地介绍这三个领域

我的教程幻灯片,对您来说都很好并且带有注释,并且涵盖了整个堆栈。


谢谢您提供的翔实答案,请仔细阅读您所附加的链接
DD

3

去年秋天,我们建立了一个相当复杂的(领域复杂性)项目,老实说,将前期工作放到BDD中可以节省项目。我已经看到域复杂性和BDD的好处之间有很强的相关性。

让我摆脱一件事:测试复杂的业务规则很困难。问题是,您是否想在每次更改时都尝试并记住所有疯狂的情况,还是希望该安全网在违反规格时通知您。花费前期时间并计算出所有场景,将它们写下来,最后为它们编写所有测试。

而当您稍后回来尝试弄清事情时,拥有可测试的规范可以节省生命。


1

BDD是基于TDD(测试驱动开发)的开发过程,以下是根据我的个人经验得出的TDD的一些优缺点:

  • TDD,请确保您的范围定义正确。这样,您可以首先设计测试用例。从而为您应该编写的代码设置期望。
  • TDD是保护代码的一种方法。假设您编写了一个简单的函数,然后在此同一函数中添加了一些复杂的切换条件。明天,如果其他人想要修改此功能,则可以参考测试用例。如果他想更改您的功能,那么(大多数情况下)他也必须更改测试用例。这使他/她能够理解您所写内容背后的原因。
  • TDD允许更快的软件开发。我们每个人在编码时都会遇到这个问题。我们从一个想法开始。并慢慢失去它。我们最终将不需要的代码段用于处理某些情况。在TDD中,您预先设置了期望。因此,您限制自己不要偏离目标太远。
  • TDD允许您在项目上线之前捕获可能的错误。这主要与编写的测试用例的质量有关。

缺点:

  • 首先,TDD可能会有些棘手。许多人不了解驱动开发的测试用例的概念。
  • TDD有时会导致维护方面的巨大努力。这与不需要的或毫无意义的测试用例有关。
  • TDD必须带一点盐。没有开发人员喜欢花时间在别人编写的某个测试用例上。理解测试用例的含义有时可能会引起严重的头痛。

我从事的项目超过90万行代码。我仍然遵循BDD。您需要考虑的一件事是纯粹由于测试用例而可能捕获的可能错误的数量。几年后,您将对BDD发誓!


2
你应该更多地讨论BDD和TDD之间的差异在哪里了DDD部分的用武之地
本杰明Gruenbaum

1
@BenjaminGruenbaum理想情况下,BDD和TDD之间没有区别。正确遵循BDD与TDD相同!因此,我认为没有任何理由将差异作为答案的一部分。还是)感谢你的建议!
2013年

1
“ TDD可以加快软件开发速度。” 有没有研究证实这一点?只是好奇。我还要提到加速不是线性的。

2
@AlexandreMartins哈,绝对!认识到您的测试和方案质量可能比假装它们都是好IMO更为重要。
Lunivore

2
@Lunivore是的,这就是BDD / TDD的困扰。测试用例必须坚固。不幸的是,开发社区中有这样一种观点,只要有测试用例就可以了!我曾经看到一个测试用例,其中使用sql语句将一行插入表中,并且在下一步中将其置为有效!开发人员是否正在尝试测试oracle功能?
2013年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.