Cucumber旨在通过协作创建每个人都能理解的场景,帮助业务利益相关者参与改进开发人员和测试人员对系统的理解.
吸引业务利益相关者的行为得到回报,因为每个人都能更好地理解,他们开始分享相同的语言,并将该语言带入代码中(参见领域驱动设计的"无所不在的语言"),这可以带来更好的估计,范围的提升,围绕实现相同目标的选项等的对话等.
当然还有其他方法可以实现目标.例如,在我们的C#项目中,我们通过场景进行讨论,将它们写在维基上,然后使用一些自定义的域特定语言来实现它们,就像这样.可以在Ruby中完成同样的事情.
BDD是学习我们认为我们知道自己在做什么的地方的过程,但事实证明我们错了 - 发现了无知.通过功能注入和单元级示例,这可以在多个粒度级别上发生,一直到项目愿景本身.它往往会为自己付出代价,但您不需要BDD框架来进行BDD.
BDD中的对话是重要的部分,而不是用于捕获它们的工具(我帮助编写JBehave并且仍然相信这是真的).自动化回归测试对于减少随着代码库增长而增加的手动工作也很重要,而Cucumber,DSL和其他BDD工具为您提供了一个非常好的副产品,它也可以帮助您跟踪和驱逐共享的理解.
编辑:我应该提到步骤的重用也很重要,但无论你使用BDD框架还是DSL,它都没有多大区别.它确实在DSL之间产生差异,并且只是在程序上模仿每个用户交互.
小智 6
从实用的角度来看,BDD与TDD高度同义.Rspec是一个BDD测试框架,以及Cucumber.
利益相关者可以阅读和理解黄瓜验收规范当然是一个关键优势,但仅凭这一事实并不能真正实现黄瓜的实惠.您的功能和方案应该在某种程度上具有特定性,因为为它们完成的工作会在团队开发周期的价值流中进行.
有些团队可能会让分析师在周期开始时确定工作范围.有时这位分析师会写出小黄瓜验收规范,但是无论谁写了初稿,你都会期望它们的粒度相当粗糙.他们可能无法涵盖所有不快乐的道路.
当开发人员开始工作时,他们经常会发现边缘情况和丢失的情况.此时,他们可以与分析师联系,并将此类对话的结果写入黄瓜功能.
根据我的经验,测试人员培养了更加批判的眼光,因此看到他们添加更多场景和功能并不罕见.测试人员也可能发现缺陷,这些缺陷应该添加到cukes中以保护我们免于回归.
关键是,除了为我们的代码提供可执行文档之外,Cucumber还提供了一个存储库,用于了解团队对话的状态以及正在开发的功能.
所有这一切都有额外的开销.但是,值得考虑的是团队流程中已经有多少开销,Cucumber可能会为此简化流程.我发现Cucumber有助于减少团队室内外通信中发生的捶打量.
我还应该提到黄瓜是用于全堆验收测试,因此相对于单元测试,黄瓜应该不那么细粒度.黄瓜不是单元和集成测试的良好替代品.我也绝不会建议使用黄瓜来验证应用UI的审美方面.只需使用它来验证用户在使用您的应用时可能采取的操作.
| 归档时间： |
|
| 查看次数： |
2123 次 |
| 最近记录： |