我对rspec [ Ruby]和specs [Scala]有点熟悉.星期六我通过了Cucumber的导师.我不喜欢Cucumber的是除了描述场景之外(就像你将使用spec或xUnit样式的测试一样),你必须实现额外的间接层：将场景步骤
利益相关者可以阅读和理解黄瓜验收规范当然是一个关键优势,但仅凭这一事实并不能真正实现黄瓜的实惠.您的功能和方案应该在某种程度上具有特定性,因为为它们完成的工作会在团队开发周期的价值流中进行.
有些团队可能会让分析师在周期开始时确定工作范围.有时这位分析师会写出小黄瓜验收规范,但是无论谁写了初稿,你都会期望它们的粒度相当粗糙.他们可能无法涵盖所有不快乐的道路.
当开发人员开始工作时,他们经常会发现边缘情况和丢失的情况.此时,他们可以与分析师联系,并将此类对话的结果写入黄瓜功能.
根据我的经验,测试人员培养了更加批判的眼光,因此看到他们添加更多场景和功能并不罕见.测试人员也可能发现缺陷,这些缺陷应该添加到cukes中以保护我们免于回归.
关键是,除了为我们的代码提供可执行文档之外,Cucumber还提供了一个存储库,用于了解团队对话的状态以及正在开发的功能.
所有这一切都有额外的开销.但是,值得考虑的是团队流程中已经有多少开销,Cucumber可能会为此简化流程.我发现Cucumber有助于减少团队室内外通信中发生的捶打量.
我还应该提到黄瓜是用于全堆验收测试,因此相对于单元测试,黄瓜应该不那么细粒度.黄瓜不是单元和集成测试的良好替代品.我也绝不会建议使用黄瓜来验证应用UI的审美方面.只需使用它来验证用户在使用您的应用时可能采取的操作.