This isn't a direct answer, but I disagree with a premise in your question but have a solution, so I'll give my opinion anyways.
one's that other Cucumber users would consider idiomatic and antipattern-free
This statement, I think, is unfortunately impossible to satisfy.
Here's Brandon Keepers of CollectiveIdea taking a commonly held position that you should strive towards generic, reusable steps, which makes sense from a general "Don't Repeat Yourself" perspective.
However, here's Aslak Hellesøy, the author of Cucumber, taking an also commonly held (but mutually exclusive) opinion that you should strive towards scenario-specific steps, which makes sense from the perspective of "why Cucumber at all?"
From "The Training Wheels Came Off" linked above, Aslak makes two example scenarios to poignantly contrast the two styles: reusable steps vs scenario-specific.
After years of using Cucumber in both styles, and considering the above dilemma, these are my conclusions:
Reusable steps become a maintenance nightmare as you need to support more complex step definitions while also avoiding naming conflicts.
Scenario-specific steps are preferred for readability and simplicity, but also become a maintenance nightmare just due to naming conflicts.
So, I've decided that Cucumber is currently broken, and plain Capybara on top of your favorite unit testing framework is the most flexible.
Cucumber could, if they chose, add scenario contexts, feature-specific scenarios, scenario namespaces, etc such that you could scope your scenarios somehow - by feature, user role, whatever makes sense - and greatly reduce naming conflicts to make scenario-specific steps truly viable. At that point, I think there would be a clear stylistic winner. Until then, there will always be this tension of needing to abstract your steps to avoid naming conflicts vs wanting to keep them scenario-specific for simplicity & readability.
I was looking for Cucumber projects as well. And actually there is wiki page on Cucumber's repository with a list of such projects (not all of them are still using Cucumber though):
Update: As mentioned by Ivailo Bardarov, they use websteps which is a bad practice at present. Just look at this as a reference to see good features and not steps!
Update 2: I think off-late, I learned a lot from following cucumber features provided with paid version of Object on Rails book. The source code is not open-source so I cannot post it here or could not find a link to it.
My preferred way is to keep feature language close to domain / business language rather than specific steps or filling in form. So instead of having something like this in my features:
When I fill in "Name" with "XYZ
I will have my feature say:
When I create a project:
| name |
| xyz |
And then my step would have, the code to click the link, parse the table and fill the relevant form field etc.
We're using Cucumber on my current project for a web app redesign, but it's not open source, so I can't offer an actual set of features and steps.
I will say that we've been heavily inspired by the Page Objects pattern in these twosamples. We're in the middle of heavy UI refactoring with out UX team. Using Page Objects has made adapting the tests to those changes reasonably simple.
You really need to abstract with page objects. Even then when your app gets past 30 screens of input your tests get hard to abstract.
I have an experimental way of quickly abstracting common paths without cycles; should probably clean it up and send it as a pull request to Cheezy: https://github.com/cheezy/page-object
A common issue with large projects is that the Cucumber features take a lot of time to write.
So there are a number of strategies involved: If you are using Cucumber to describe a legacy system, you get decent acceptance test coverage via cucumber and capybara, and then refactor your cucumber step definitions.
If you are unit testing properly, use Cucumber to only describe the happy path of your app, or only essential non-happy paths. Get coverage with RSpec (or Xunit of choice).
The key issues with Cucumber is that the features should be describing functionality at a very high level. You need to make your step definitions DRY and reusable, and I am a fan of redirecting step definitions to keep the stakeholder-interesting features concise and to the point. Though I think that point can be a bit contentious.
发布评论
评论（8）
您可以阅读 diaspora 黄瓜测试。这是一个相当大的项目，所以我认为你可以从中学到一些东西。
You can read diaspora's cucumber tests. It's a pretty big project so I think you can learn something from it.
你可以阅读 Cucumber 本身的功能，这些人应该知道他们在做什么：
https ://github.com/cucumber/cucumber-ruby/tree/master/features
You can read the features of Cucumber itself, the guys should know what they are doing:
https://github.com/cucumber/cucumber-ruby/tree/master/features
这不是直接答案，但我不同意你问题中的前提，但有解决方案，所以无论如何我都会给出我的意见。
。不幸的是，我认为这种说法是不可能满足的。
CollectiveIdea 的 Brandon 守护者采取的普遍立场是 您应该努力实现通用的、可重用的步骤，这从一般的“不要重复自己”的角度来看是有意义的。
然而，Cucumber 的作者 Aslak Hellesøy 也提出了一个普遍持有的（但相互排斥的）观点：您应该努力采取针对特定场景的步骤，从“为什么选择 Cucumber？”的角度来看，这是有意义的。
从上面链接的“训练轮脱落”中，阿斯拉克制作了两个示例场景来鲜明对比这两种风格：可重用步骤 与特定场景。
经过多年以两种方式使用 Cucumber 并考虑到上述困境，以下是我的结论：
所以，我认为 Cucumber 目前已经被破坏，而在你最喜欢的单元测试框架之上的普通 Capybara 是最灵活的。
如果他们选择的话，Cucumber 可以添加场景上下文、特定于功能的场景、场景命名空间等，这样您就可以以某种方式（按功能、用户角色、任何有意义的内容）来确定场景的范围，并大大减少命名冲突，以制定特定于场景的步骤真正可行的。到那时，我认为将会有一个明显的风格赢家。在那之前，总是存在着这样的紧张：需要抽象你的步骤以避免命名冲突，而不是为了简单和希望保持它们特定于场景。可读性。
试图解决这些缺点的另一个项目是 Spinach，但该项目并不是那么活跃。 查看我关于菠菜与黄瓜评估的评论。
This isn't a direct answer, but I disagree with a premise in your question but have a solution, so I'll give my opinion anyways.
This statement, I think, is unfortunately impossible to satisfy.
Here's Brandon Keepers of CollectiveIdea taking a commonly held position that you should strive towards generic, reusable steps, which makes sense from a general "Don't Repeat Yourself" perspective.
However, here's Aslak Hellesøy, the author of Cucumber, taking an also commonly held (but mutually exclusive) opinion that you should strive towards scenario-specific steps, which makes sense from the perspective of "why Cucumber at all?"
From "The Training Wheels Came Off" linked above, Aslak makes two example scenarios to poignantly contrast the two styles: reusable steps vs scenario-specific.
After years of using Cucumber in both styles, and considering the above dilemma, these are my conclusions:
So, I've decided that Cucumber is currently broken, and plain Capybara on top of your favorite unit testing framework is the most flexible.
Cucumber could, if they chose, add scenario contexts, feature-specific scenarios, scenario namespaces, etc such that you could scope your scenarios somehow - by feature, user role, whatever makes sense - and greatly reduce naming conflicts to make scenario-specific steps truly viable. At that point, I think there would be a clear stylistic winner. Until then, there will always be this tension of needing to abstract your steps to avoid naming conflicts vs wanting to keep them scenario-specific for simplicity & readability.
An alternative project that attempts to address these shortcomings is Spinach, but the project isn't all that active. See my comments here about an evaluation of Spinach vs Cucumber.
我也在寻找黄瓜项目。实际上，Cucumber 的存储库上有一个 wiki 页面，其中包含此类项目的列表（尽管并非所有项目都仍在使用 Cucumber）：
使用 Cucumber 的项目：
/generators/clearance_features/templates/features//features//plugins/*/features/features/features/features//features/来源：< /strong> https://github.com/cucumber/cucumber/wiki/Projects-Using-Cucumber
I was looking for Cucumber projects as well. And actually there is wiki page on Cucumber's repository with a list of such projects (not all of them are still using Cucumber though):
Projects using Cucumber:
/generators/clearance_features/templates/features//features//plugins/*/features/features/features/features//features/Source: https://github.com/cucumber/cucumber/wiki/Projects-Using-Cucumber
我推荐：
https://github.com/teambox/teambox/tree/dev/features< /a>
更新：正如 Ivailo Bardarov 提到的，他们使用 websteps，目前这是一种不好的做法。只需将此作为参考即可查看良好的功能而不是步骤！
更新 2：我认为已经很晚了，我从付费版《Object on Rails》书中提供的 Cucumber 功能中学到了很多东西。源代码不是开源的，所以我无法将其发布在这里或找不到它的链接。
我的首选方法是使功能语言接近领域/业务语言，而不是具体步骤或填写表格。因此，我的功能中不会有这样的内容：
我会让我的功能说：
然后我的步骤将包含用于单击链接、解析表格并填写相关表单字段等的代码。
I recommend:
https://github.com/teambox/teambox/tree/dev/features
Update: As mentioned by Ivailo Bardarov, they use websteps which is a bad practice at present. Just look at this as a reference to see good features and not steps!
Update 2: I think off-late, I learned a lot from following cucumber features provided with paid version of Object on Rails book. The source code is not open-source so I cannot post it here or could not find a link to it.
My preferred way is to keep feature language close to domain / business language rather than specific steps or filling in form. So instead of having something like this in my features:
I will have my feature say:
And then my step would have, the code to click the link, parse the table and fill the relevant form field etc.
我们在我当前的项目中使用 Cucumber 来重新设计 Web 应用程序，但它不是开源的，因此我无法提供一组实际的功能和步骤。
我想说的是，我们受到了这两个两个 示例。我们正在进行大量的 UI 重构，但没有 UX 团队。使用页面对象使测试适应这些变化变得相当简单。
We're using Cucumber on my current project for a web app redesign, but it's not open source, so I can't offer an actual set of features and steps.
I will say that we've been heavily inspired by the Page Objects pattern in these two samples. We're in the middle of heavy UI refactoring with out UX team. Using Page Objects has made adapting the tests to those changes reasonably simple.
我希望我可以发布我们公司存储库（财富 500 强的大型内部 Web 应用程序）中的内容。
最好的可能是维基百科的测试：
https://github.com/wikimedia/qa-browsertests
你确实需要用页面对象进行抽象。即使如此，当您的应用程序输入超过 30 个屏幕时，您的测试也很难抽象。
我有一种实验方法可以快速抽象出没有循环的公共路径；也许应该清理它并将其作为拉取请求发送给 Cheezy： https://github.com/cheezy/页面对象
I wish I could post the ones from our corporate repo (massive internal web app for a Fortune 500).
The best in the wild is probably Wikipedia's tests:
https://github.com/wikimedia/qa-browsertests
You really need to abstract with page objects. Even then when your app gets past 30 screens of input your tests get hard to abstract.
I have an experimental way of quickly abstracting common paths without cycles; should probably clean it up and send it as a pull request to Cheezy: https://github.com/cheezy/page-object
大型项目的一个常见问题是 Cucumber 功能需要花费大量时间来编写。
因此，涉及到许多策略：
如果您使用 Cucumber 来描述遗留系统，您可以通过 cucumber 和 capybara 获得不错的验收测试覆盖率，然后重构您的 Cucumber 步骤定义。
如果您正确进行单元测试，请仅使用 Cucumber 来描述应用程序的快乐路径，或仅描述必要的非快乐路径。使用 RSpec（或选择的 Xunit）获得覆盖。
Cucumber 的关键问题是特性应该在非常高的级别上描述功能。您需要使步骤定义干燥且可重用，并且我喜欢重定向步骤定义，以保持利益相关者感兴趣的功能简洁明了。尽管我认为这一点可能有点争议。
A common issue with large projects is that the Cucumber features take a lot of time to write.
So there are a number of strategies involved:
If you are using Cucumber to describe a legacy system, you get decent acceptance test coverage via cucumber and capybara, and then refactor your cucumber step definitions.
If you are unit testing properly, use Cucumber to only describe the happy path of your app, or only essential non-happy paths. Get coverage with RSpec (or Xunit of choice).
The key issues with Cucumber is that the features should be describing functionality at a very high level. You need to make your step definitions DRY and reusable, and I am a fan of redirecting step definitions to keep the stakeholder-interesting features concise and to the point. Though I think that point can be a bit contentious.