Logo: Relish

  1. Sign in

Project: Bf-cukes


Notes on Cucumber

Feel free to add tags (such as @manual @wip to the various scenarios). When running tests we can run specific tags if need be.
What I would like to get is a subset of all of our features/scenarios to be identified as a "smoke test" (ideally, tagged as @smoke).
These would be the core functionality of the product, without getting into the nitty-gritty.


Features should be broken out into seperate .feature files. This is how cucumber will run them. This also makes it easier to read and find specific areas of the app. Additionally, do not number the Features or Scenarios, as that is not how the gherkin syntax works. I would recommend using some text editor (such as sublime 3) to edit
.feature files. Make sure you install a cucumber/gherkin syntax highlighter (and possibly formatter) to make it a bit easier to create these file types.


These all look really great. One area that I think we need some improvement on is what it takes to get to a certain state. They way I want to see test made is that they are all self inclusive. What I mean by that is that if you were to rip out this test and run it just by itself, it should be able to work fine. To achieve this, tests may need a bit of setup.

Additionally, and this is where it can get a bit hard, but steps should be fairly concise. What I don't want to see is a huge long step that does tons of action in the end. These kinds of steps should be broken down into other steps (which makes it easier to read, and makes these steps more reusable).
Cucumber has some features where if we want to make a compound step, we can add various steps into this compound step, but for now, it's best to keep them short and concise.

One more thing, you need to consider what settings are enabled/disabled while the tests are being run. Never assume that some setting will be on, you need to explicitly set those settings.
If you look at some of my scenarios you can see how I setup the settings (usually in a Background step).

Background steps

You can use a Background condition to run duplicated steps before each case, this can save alot of typing/repetition. If you check out the repository, you can see how I use this.


I've created various folders and put the tests in them. I try to make folders based on functionality on the site to organize the cukes.

Description of Feature

Each feature should only have 1 description for it (the text that goes beneath the "Feature:..." at the top). I usually put it in a format like:

Because I am something/want to do something
When I perform an action
I expect this result


I formatted all of the tests in this repo, please follow this same formatting (as seen below)

Feature: Base level indent

    Description is
    Indented only

    Background: Is the same as description, if you have one.
        Given Steps are then indented once from the scenario/background.

    Scenario: Is, again, the same as the description.
        Given Steps are then indented once from the scenario/background.
        When another step
        Then my last step

    @Tag @Bob
    Scenario: A tag can just be like above, you can put multiple if need be
        Given test step
        When another step
        Then final step

Areas we can't/are difficult to automate

  • Emails
  • Visual issues


  1. Community settings features
  2. Post features
  3. Question features
  4. Series features

Last published over 7 years ago by blubecker.