Scenario is another Gherkin keyword that helps express the business scenario under test. It captures the high-level intent of the scenario. The typical syntax is as shown:

Scenario: Scenario name

A feature can be broken down into multiple scenarios, and these scenarios constitute business use cases together. If you add up all the scenarios' behavior, it should be equivalent to the feature behavior itself.

So, a scenario basically contains the steps run on the system under test and gives feedback. For a scenario to pass in Cucumber, all steps under it should pass. Each scenario can have multiple steps describing the behavior. There is no rule for the number of steps within a scenario; however, care should be taken to keep the readability intact.

Gherkin gives us keywords to help express these steps; they are Given, When, Then. Any testing scenario is generally categorized into the following:

• Getting the system to a desired state
• Performing the steps to test
• Verifying

The mentioned steps are typically mapped to Given, where we get the system in a desired state, When, where we perform the actual testing steps (this can be a bunch of lines) and lastly, Then, where we do the verification of the desired state of the application. Let's look at the feature file we wrote earlier:

    Given I launch the app
    When I choose "Bangalore" as my city
    And I search for "Honda City" under Used Cars
    Then I should see the first car search result with "Honda"

So, Given sets the application state that is about launching the desired application; When is telling the application to move to a particular state by choosing a city and searching for specified cars in our case, and Then is about verifying that the first car result is the desired one.

Gherkin allows you to replace the entire set of Given, When, and Then in a little less verbose way by replacing it with *. So, the earlier statement can be expressed as follows:

* I launch iOS app
* I choose to enter "22" and "33"
* I tap on Compute Sum
* I should see the result "55"

Now that we have read about feature files, scenarios, and steps, let's take a look at the result states Cucumber gives. Cucumber has multiple states for the results: Undefined, Pending, Passed, and Failed.

Undefined steps: When Cucumber doesn't find the step definition that matches a step, it marks the step as undefined and throws the undefined step exception when we try to run it. For the preceding steps, it will throw the shown exception:

Undefined step: I launch iOS app

Pending steps: Cucumber isn't able to figure out whether a step is defined or not. It starts looking at the step definition and then figures out the state of the step, that is, whether it is defined or not. Generally, when a new step is created, this is the template:

@Given("^I launch iOS app$")
 public void iLaunchIOSApp() throws Throwable {
     // Write code here that turns the phrase above into concrete 
     actions
     throw new PendingException();
 }

So, when the Cucumber runner encounters the throw new PendingException() statement, it throws up the pending steps exception.

Passed: If a code block executes successfully without throwing any exception, Cucumber marks that step as passed.

Failed: If a code block throws some exception, Cucumber marks that step as failed and skips the remaining steps (if any). The standard reason for exception is, generally, system not behaving as expected, which is a bug in the app or bug in the step definition code itself. The assertion failures also mark the step to be failed, thereby failing the scenario.

Let's look at another important Gherkin keyword--Background.