What is Cucumber Feature File & Step Definition? (Example)

For every cucumber project there is a single directory at the root of the project named “features“. This is where all of your cucumber features will reside. In this directory you will find additional directories, which is step_definition and support directories.

That layout matters, because Cucumber discovers your files by convention rather than by configuration. A feature file that sits outside the features directory is simply never read.

What is “Feature File”?

Features file contain high level description of the Test Scenario in simple language. It is known as Gherkin. Gherkin is a plain English text language.

Cucumber Feature File consist of following components —

• Feature: A feature would describe the current test script which has to be executed.
• Scenario: Scenario describes the steps and expected outcome for a particular test case.
• Scenario Outline: Same scenario can be executed for multiple sets of data using scenario outline. The data is provided by a tabular structure separated by (I I).
• Given: It specifies the context of the text to be executed. By using datatables “Given”, step can also be parameterized.
• When: “When” specifies the test action that has to performed.
• Then: The expected outcome of the test can be represented by “Then”.

One file holds one Feature. The scenarios below it are the concrete examples that illustrate the feature, and each scenario follows the same rhythm: describe a starting context, describe an event, describe the expected result.

Next, we will learn how to write Feature File in Cucumber with example.

Sample Feature File Example:

The original example published with this tutorial is reproduced below exactly as written.

Feature: Visit career guide page in career.guru99.com
Scenario: Visit career.guru99.com
Given: I am on career.guru99.com
When: I click on career guide menu
Then: I should see career guide page

⚠️ Correction: the example above places a colon after Given, When and Then. Gherkin puts a colon after Feature and Scenario only. A step keyword followed by a colon does not parse as a step, so Cucumber silently ignores the line. The corrected file reads as follows.

Feature: Visit career guide page in career.guru99.com

  Scenario: Visit career.guru99.com
    Given I am on career.guru99.com
    When I click on career guide menu
    Then I should see career guide page

Indentation is not required by the parser, but two spaces per level is the conventional style and makes a long feature far easier to scan. The animation below shows a feature file being run and each step turning green as it passes.

What is “Step Definition”?

Step definition maps the Test Case Steps in the feature files(introduced by Given/When/Then) to code. It which executes the steps on Application Under Test and checks the outcomes against expected results. For a step definition to be executed, it must match the given component in a feature. Step definition is defined in ruby files under “features/step_definitions/*_steps.rb”.

The match is made on the text of the step alone. Cucumber does not take the keyword into account when it looks for a definition, which is why two steps in the same suite may never carry identical text even if one is a Given and the other a Then.

Example for Step Definition: Here we will use above Cucumber Feature File example of browsing career.guru99.com. We will use features like “When, Then, Given ” as shown in the below Cucumber Feature File examples.

Step 1:

Given (/^ I am on career.guru99.com$/) do

Browser.goto "http://career.guru99.com" -This will visit career.guru99 on browser

end

Step 2:
When (/^ click on career guide menu$/) do

Browser.text (:name, " career guide" ).click – This will click "career guide menu"

end

Step 3:

Then (/^ I should see career guide page$/) do

Browser.goto "http://career.guru99.com/category/career-guide/" - It will visit "career guide page"

end

⚠️ A note on languages: the definitions above are Ruby, which is where Cucumber started and which is why the folder is named step_definitions and the files end in _steps.rb. The same feature file drives step definitions written in Java, JavaScript, Python or C# without a single change to the Gherkin. In Cucumber-JVM the regular expression moves into an annotation on a method:

@Given("I am on career.guru99.com")
public void i_am_on_the_career_page() {
    driver.get("http://career.guru99.com");
}

Whichever language you choose, the step definition is the only place implementation detail belongs. Keeping selectors and HTTP calls out of the feature file is what lets a non-programmer read the scenario. The first Cucumber script walkthrough builds this pairing end to end.

Scenario Outline and Examples in a Feature File

Copying a scenario three times to change one value is the most common way a feature file becomes unreadable. Scenario Outline replaces the copies with a template, and an Examples table supplies the values.

Parameters are written inside angle brackets and must match a column heading in the table below them. Cucumber substitutes the values before it looks for a matching step definition, so the definitions themselves need no special handling.

Scenario Outline: Search the career guide
  Given I am on career.guru99.com
  When I search for "<keyword>"
  Then I should see the <section> section

  Examples:
    | keyword   | section       |
    | interview | Interview Tips|
    | resume    | Resume Guide  |

A few points are worth remembering when using outlines:

• The outline runs once per data row. The first row is the header and is never executed.
• A Scenario Outline must be followed by at least one Examples section, otherwise nothing runs.
• The table pipes do not need to line up, although aligning them keeps the file readable.
• Keep the table small. A table with thirty rows is usually a sign the data belongs in a data-driven test instead.

Background, And, But and the Other Gherkin Keywords

Beyond the six components listed earlier, Gherkin has a handful of keywords that keep longer feature files readable.

• Background — a block of Given steps that runs before every scenario in the feature. It removes the repetition of writing the same precondition at the top of each scenario.
• And and But — replacements for a repeated Given, When or Then. They read better and behave identically; Cucumber matches on the step text either way.
• Rule — an optional grouping, added in Gherkin 6, that collects the scenarios illustrating one business rule.
• Doc Strings — a block of text fenced by three double quotes, passed to the step definition as a single argument when one line is not enough.
• Data Tables — pipe-delimited rows attached to a single step, used to hand a list of values to that step.
• Tags — labels beginning with an at sign, placed above a Feature or Scenario so that a subset can be selected at run time.
• Comments — a line beginning with a hash. Comments are only allowed at the start of a line, and Gherkin has no block comment.

Put together, a feature file with shared setup looks like this:

Feature: Career guide navigation

  Background:
    Given I am on career.guru99.com

  Scenario: Open the career guide menu
    Given I am signed in
    And my profile is complete
    When I click on career guide menu
    Then I should see career guide page
    But I should not see the admin panel

Common Feature File Mistakes and How to Fix Them

Most Cucumber problems reported by beginners are not framework faults. They are small violations of the Gherkin rules that fail quietly.

Fixing these before the suite grows is far cheaper than fixing them afterwards, because every scenario written in the meantime copies the same shape. Once the feature files behave, the next step is wiring the project up — see the Cucumber installation walkthrough and the wider automation testing series.

FAQs