Good Cucumber examples in the wild? [closed]
I've tried Cucumber for a few projects a couple of years ago and am looking to give it another go. I don't really need another "Beginning Cucumber" article. Instead, I'd like to see some actual uses in the wild—one's that other Cucumber users would consider idiomatic and antipattern-free.
So, in your opinion, what are the best examples of actual Cucumber specs in large projects?
You can read diaspora's cucumber tests. It's a pretty big project so I think you can learn something from it.
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
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.
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.
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:
- 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
Source: https://github.com/cucumber/cucumber/wiki/Projects-Using-Cucumber