60

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?

AndrewO
  • 1,590
  • 1
  • 17
  • 24
  • 1
    If you come back to this, maybe you should change the accepted answer from diaspora. – KobeJohn Feb 05 '12 at 13:35
  • look into http://en.wikipedia.org/wiki/Specification_by_example for perspective on using acceptance tests as feature specs and https://github.com/cheezy/page-object as a way to reduce UI coupling in Cucumber. – Brenden Oct 18 '13 at 00:21

8 Answers8

38

You can read diaspora's cucumber tests. It's a pretty big project so I think you can learn something from it.

Vasiliy Ermolovich
  • 24,459
  • 5
  • 79
  • 77
  • 3
    That's a good example project, although the tight coupling to the UI will make the scenarios unnecessarily brittle IMHO. Have a look at this post on [Selector-free cucumber scenarios](http://bjeanes.com/2010/09/19/selector-free-cucumber-scenarios). – Town Apr 21 '11 at 16:30
  • 16
    The Diaspora Cucumber features are really quite bad. Not a good place to learn from. – Andy Waite Apr 26 '11 at 08:51
  • 3
    At quick glance I see a lot of 'And I wait for the ajax to finish' this has to be bad! – tpower Nov 19 '12 at 17:28
  • 3
    Those features are too imperative! – Andrei Botalov Feb 08 '13 at 21:16
  • @AndreyBotalov too imperative? That depends on if you're using the acceptance tests in defining your user stories. If you are, then imperative steps are imperative! ;) Declarative steps are too vague for that use. – Brenden Oct 17 '13 at 23:50
  • @AndyWaite bad how? If you mean too imperative, then I would remind you that UI coupling has to occur somewhere; in the gherkin steps or in the ruby step definitions. Imperative vs declarative is the wrong bone to pick. – Brenden Oct 17 '13 at 23:51
  • My comment was from 2.5 years ago, I expect they have improved since then. – Andy Waite Oct 18 '13 at 10:44
17

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

Michael Kohl
  • 66,324
  • 14
  • 138
  • 158
14

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:

  1. Reusable steps become a maintenance nightmare as you need to support more complex step definitions while also avoiding naming conflicts.
  2. 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.

Community
  • 1
  • 1
Woahdae
  • 4,951
  • 2
  • 28
  • 26
  • See also, [turnip](https://github.com/jnicklas/turnip), which transforms gherkin into rspec steps. Similar to Spinach, but a bit more active. – Woahdae Mar 04 '16 at 23:51
10

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:

Source: https://github.com/cucumber/cucumber/wiki/Projects-Using-Cucumber

Kirill
  • 1,530
  • 5
  • 24
  • 48
6

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:

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.

Chandresh Pant
  • 1,173
  • 15
  • 19
  • 4
    Most of the features in this project are using websteps which is bad practice for example https://github.com/teambox/teambox/blob/dev/features/organization_create.feature – Ivailo Bardarov Dec 04 '12 at 10:53
  • Yes, thats correct. They are a bit old now. But their features definitions are nonetheless pretty cool! No one uses websteps nowadays. I have some more examples which I check and post. – Chandresh Pant Dec 06 '12 at 02:14
3

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

Chad Brewbaker
  • 2,523
  • 2
  • 19
  • 26
  • I just noticed the "Page Object" concept for the first time in these Wikipedia tests you mentioned. Seems interesting. I will have to look into it more. – Andrew Jan 23 '14 at 06:25
  • The page object concept works on embedded C too. You write one "page object" for each functional state of your application that you want to interact with. – Chad Brewbaker Jan 23 '14 at 17:14
3

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.

Mike Cornell
  • 5,909
  • 4
  • 29
  • 38
2

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.

Richard Conroy
  • 1,880
  • 1
  • 12
  • 4