野外的好黄瓜例子？ [关闭]答案

【问题标题】：Good Cucumber examples in the wild? [closed]野外的好黄瓜例子？ [关闭]
【发布时间】：2020-02-18 21:18:26
【问题描述】：

几年前，我在几个项目中尝试过 Cucumber，并希望再试一次。我真的不需要另一篇“Beginning Cucumber”文章。相反，我希望看到一些实际用途——其他 Cucumber 用户会认为是惯用且无反模式的用途。

那么，在您看来，大型项目中实际 Cucumber 规范的最佳示例是什么？

【问题讨论】：

如果你回到这一点，也许你应该改变从散居国外接受的答案。
查看 en.wikipedia.org/wiki/Specification_by_example 以了解使用验收测试作为功能规范和 github.com/cheezy/page-object 作为减少 Cucumber 中 UI 耦合的一种方式。

标签： ruby cucumber bdd

【解决方案1】：

您可以阅读diaspora's 黄瓜测试。这是一个相当大的项目，所以我认为你可以从中学到一些东西。

【讨论】：

这是一个很好的示例项目，尽管与 UI 的紧密耦合会使场景变得不必要地脆弱恕我直言。看看Selector-free cucumber scenarios上的这篇文章。
Diaspora Cucumber 的功能真的很糟糕。不是一个学习的好地方。
一目了然，我看到很多“我等待 ajax 完成”，这一定很糟糕！
这些功能太必要了！
@AndreyBotalov 太迫切了？这取决于您是否在定义用户故事时使用验收测试。如果你是，那么势在必行的步骤是势在必行的！ ;) 声明性步骤对于该用途来说太模糊了。

【解决方案2】：

你可以阅读Cucumber本身的特性，大伙应该知道他们在做什么：

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

【讨论】：

【解决方案3】：

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

其他 Cucumber 用户会认为是惯用且无反模式的

不幸的是，我认为这个陈述是不可能满足的。

CollectiveIdea 的 Brandon Keepers 采取了 you should strive towards generic, reusable steps 的共同立场，从一般的“不要重复自己”的角度来看，这是有道理的。

但是，Cucumber 的作者 Aslak Hellesøy 提出了一个同样普遍（但相互排斥）的观点，即 you should strive towards scenario-specific steps，从“为什么是 Cucumber？”的角度来看这是有道理的。

从上面链接的“训练车轮脱落”中，Aslak 制作了两个示例场景来强烈对比两种风格：reusable steps 与 scenario-specific。

在这两种风格中使用 Cucumber 多年后，考虑到上述困境，以下是我的结论：

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

所以，我决定 Cucumber 目前已经坏掉了，在你最喜欢的单元测试框架之上的普通 Capybara 是最灵活的。

如果 Cucumber 愿意，可以添加场景上下文、特定于功能的场景、场景命名空间等，以便您可以以某种方式确定场景的范围 - 按功能、用户角色等任何有意义的方式 - 并大大减少命名冲突以制作场景- 真正可行的具体步骤。到那时，我认为会有一个明显的风格赢家。在那之前，总是会存在这样一种压力：需要抽象您的步骤以避免命名冲突，而不是希望将它们保持在特定于场景以实现简单性和可读性。

另一个试图解决这些缺点的项目是Spinach，但该项目并不是那么活跃。 See my comments here about an evaluation of Spinach vs Cucumber.

【讨论】：

另请参见turnip，它将小黄瓜转换为 rspec 步骤。类似于菠菜，但更活跃。

【解决方案4】：

我也在寻找 Cucumber 项目。实际上，在 Cucumber 的存储库中有一个 wiki 页面，其中列出了此类项目（并非所有项目都仍在使用 Cucumber）：

使用 Cucumber 的项目：

Gemcutter
Clearance/generators/clearance_features/templates/features/
WebJam/features/
Redcar/plugins/*/features
jeweler/features
jekyll/features
CarrierWave/features/
RadiantCMS
OERPScenario (linked to OpenERP)
WontoMedia/features/
Rails directory
Broth
Heroku Suspenders
TimeFliesBy
Diaspora
Chef

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

【讨论】：

【解决方案5】：

更新：正如 Ivailo Bardarov 所提到的，他们使用 websteps，这是目前一种不好的做法。只需将此作为参考，以查看好的功能而不是步骤！

更新 2：我觉得有点晚了，我从以下付费版 Object on Rails 书中提供的黄瓜功能中学到了很多东西。源代码不是开源的，所以我无法在此处发布或找不到指向它的链接。

我首选的方法是使功能语言接近领域/业务语言，而不是具体步骤或填写表格。所以不要在我的功能中使用这样的东西：

When I fill in "Name" with "XYZ

我会让我的功能说：

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

然后我的步骤将是点击链接、解析表格并填写相关表单字段等的代码。

【讨论】：

这个项目中的大部分功能都使用 websteps，这是不好的做法，例如 github.com/teambox/teambox/blob/dev/features/…
是的，没错。他们现在有点老了。但是它们的功能定义仍然非常酷！现在没有人使用 websteps。我还有一些我检查并发布的示例。

【解决方案6】：

我们在我当前的项目中使用 Cucumber 重新设计网络应用程序，但它不是开源的，所以我无法提供一组实际的功能和步骤。

我会说我们深受这些two samples 中的页面对象模式的启发。在没有 UX 团队的情况下，我们正在进行繁重的 UI 重构。使用 Page Objects 使测试适应这些变化变得相当简单。

【讨论】：

感谢这些样本。我一直在寻找有关页面对象的好信息。 :)

【解决方案7】：

我希望我可以从我们的公司回购（财富 500 强的大型内部网络应用程序）中发布那些。

最好的可能是维基百科的测试：

https://github.com/wikimedia/qa-browsertests

您确实需要使用页面对象进行抽象。即便如此，当您的应用程序超过 30 个输入屏幕时，您的测试也很难抽象。

我有一种实验性的方法可以快速抽象出没有循环的公共路径；可能应该清理它并将其作为拉取请求发送给 Cheezy：https://github.com/cheezy/page-object

【讨论】：

我刚刚在您提到的这些维基百科测试中第一次注意到“页面对象”概念。看起来很有趣。我将不得不更多地研究它。
页面对象概念也适用于嵌入式 C。您为要与之交互的应用程序的每个功能状态编写一个“页面对象”。

【解决方案8】：

大型项目的一个常见问题是 Cucumber 功能需要大量时间来编写。

因此涉及到许多策略：如果您使用 Cucumber 来描述遗留系统，您可以通过 Cucumber 和 capybara 获得不错的验收测试覆盖率，然后重构您的 Cucumber 步骤定义。

如果您正确地进行单元测试，请使用 Cucumber 仅描述您的应用程序的快乐路径，或仅描述基本的非快乐路径。使用 RSpec（或选择的 Xunit）进行覆盖。

Cucumber 的关键问题是特性应该在非常高的层次上描述功能。您需要使您的步骤定义干燥且可重用，我喜欢重定向步骤定义以保持利益相关者感兴趣的功能简洁明了。虽然我认为这一点可能有点争议。

【讨论】：