野生黄瓜的好例子？

Question

几年前我曾尝试过Cucumber的一些项目,我希望再给它一次.我真的不需要另一篇"Beginning Cucumber"文章.相反,我希望看到一些实际用途,其他黄瓜用户会考虑惯用和反模式.

那么,在您看来,大型项目中实际黄瓜规格的最佳例子是什么？

Answer 1

你可以阅读侨民的黄瓜测试.这是一个非常大的项目,所以我认为你可以从中学到一些东西.

Answer 2

您可以阅读Cucumber本身的功能,这些人应该知道他们在做什么:

https://github.com/cucumber/cucumber-ruby/tree/master/features

Answer 3

这不是一个直接的答案,但我不同意你的问题中的一个前提,但有一个解决方案,所以无论如何我会给出我的意见.

一个是其他黄瓜用户会考虑惯用和反模式

不幸的是,我认为这句话无法满足.

这里的CollectiveIdea的Brandon Keepers采取了一个共同的立场,你应该努力实现通用的,可重复使用的步骤,这从一般的"不要重复自己"的角度来看是有意义的.

然而,这里是Cucumber的作者AslakHellesøy,他也采取了一种普遍持有(但相互排斥)的观点,即你应该努力采取针对特定情景的步骤,从"为什么选择黄瓜？"的角度来看,这是有道理的.

从上面链接的"训练车轮起飞"开始,Aslak制作了两个示例场景,对两种风格形成鲜明对比:可重复使用的步骤与特定于场景的步骤.

经过多年使用Cucumber两种风格,并考虑到上述困境,这些是我的结论:

1. 可重用的步骤成为维护的噩梦,因为您需要支持更复杂的步骤定义,同时还要避免命名冲突.
2. 特定于场景的步骤是可读性和简单性的首选,但由于命名冲突而成为维护的噩梦.

因此,我认为Cucumber目前已经破产,而且您最喜欢的单元测试框架上的普通Capybara是最灵活的.

如果他们选择,Cucumber可以添加场景上下文,特定于功能的场景,场景命名空间等,这样您就可以按照某种方式调整场景的范围 - 通过功能,用户角色,任何有意义的内容 - 并大大减少命名冲突以制定特定于场景的步骤真的可行.在那一点上,我认为会有一个明确的风格赢家.在此之前,总是存在这样的紧张,需要抽象你的步骤以避免命名冲突,而不是为了简单和可读性而保持它们特定于场景.

试图解决这些缺点的另一个项目是Spinach,但该项目并不是那么活跃.请参阅我在这里关于菠菜与黄瓜评估的评论.

Answer 4

我也在寻找黄瓜项目.实际上在Cucumber的存储库中有一个wiki页面,其中列出了这些项目(但并非所有项目都使用Cucumber):

使用黄瓜的项目:

• Gemcutter
• 净空 /generators/clearance_features/templates/features/
• WebJam /features/
• 雷德卡 /plugins/*/features
• 珠宝商 /features
• 杰奇 /features
• CarrierWave /features/
• RadiantCMS
• OERPScenario(链接到OpenERP)
• WontoMedia /features/
• Rails目录
• 肉汤
• Heroku吊带
• TimeFliesBy
• 散居
• 厨师

资料来源: https ://github.com/cucumber/cucumber/wiki/Projects-Using-Cucumber

Answer 5

我建议:

https://github.com/teambox/teambox/tree/dev/features

更新:如Ivailo Bardarov所述,他们使用的是网步,这在目前是一种不好的做法.只需看看这个作为参考,看看好的功能,而不是步骤!

更新2:我认为是非常晚,我从以下黄瓜功能中学到了很多东西,这些功能都是通过付费版本的Object on Rails书籍提供的.源代码不是开源的,因此我无法在此处发布或无法找到它的链接.

我的首选方法是使特征语言保持接近域/业务语言而不是特定步骤或填写表单.所以不要在我的功能中使用这样的东西:

When I fill in "Name" with "XYZ

我的功能会说:

When I create a project:
| name |
| xyz  |

然后我的步骤将有,代码点击链接,解析表格并填写相关的表格字段等.