Automated testing training support - Cucumber.docx

Automating the acceptance criteria. Cucumber- problem: the need of a tool that automates our acceptance criteria

- answer: Cucumber

Goals:

- what is Cucumber?

- the Gherkin language. keywords

- the feature file. syntax and proper formatting. examples

- the scenario. syntax and proper formatting. examples

- step definitions. capturing arguments

- the background step

- scenario outline

- using tagsCucumber is a command-line tool. When you run it, it reads in your specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system under test. Each scenario is a list of steps for Cucumber to work through.

So that Cucumber can understand these feature files, they must follow some basic syntax rules. The name for this set of rules is Gherkin.

official site:

HYPERLINK "http://cukes.info/"http://cukes.info/https://github.com/cucumber/cucumber/wiki

supporting book: The Cucumber Book - BDD for Testers and Developers

https://github.com/cucumber/cucumber/wiki/Gherkin

Example of a feature fileFeature: Search

Scenario: Display related articlesGiven I am on the wikipedia homepageWhen I click on the search fieldAnd I enter in the search field Java programming languageAnd I click ok buttonThen I should see a list of articles related to my criteria#And I drink a cofee

Gherkin files use the .feature file extension. (plain text files)

Gherkin gives us a lightweight structure for documenting examples of the behavior our stakeholders want, in a way that it can be easily understood both by the stakeholders and by Cucumber. Although we can call Gherkin a programming language, its primary design goal is human readability, meaning you can write automated tests that read like documentation.

With the help of Gherkin, we can turn our concrete examples we discussed earlier into executable specifications. If we write the concrete examples in a way that we can pass them to a tool to check them for us, we have our automated acceptance tests.

The challenge with writing good automated acceptance tests is that, for them to be really effective, they need to be readable by not only the tool that we use but also by our stakeholders.

Gherkin comes up with some keywords that can facilitate writing the concrete examples in

Keywords: Feature, Background, Scenario, Given, When, Then, And, But, *, Scenario Outline, Examples.

FeatureEach Gherkin file begins with the Feature keyword. It just gives you a convenient place to put some summary documentation about the group of tests that follow. It does not affect the behavior of the Cucumber tests.

The text immediately following on the same line as the Feature keyword is the name of the feature, and the remaining lines are its description. You can include any in the description except a line beginning with one of the words Scenario, Background, or Scenario Outline. The description can span multiple lines.

In order for the Gherkin file to be valid, a Feature must be followed by one of the following: Scenario, Background or Scenario Outline.

ScenarioTo actually express the behavior we want, each feature contains several scenarios. Each scenario is a single concrete example of how the system should behave in a particular situation. Adding together the behavior defined by all of the scenarios, thats the expected behavior of the feature itself.

A valid scenario needs to follow the pattern:

- specify the initial context

- trigger a specific event

- states the expected outcome

Given, When, ThenIn Gherkin, we use the keywords Given, When, and Then to identify those three different parts of the scenario.

And, ButEach of the lines in a scenario is known as a step. We can add more steps to each Given, When, or Then section of the scenario using the keywords And and But. Cucumber doesnt actually care which of these keywords you use; the choice is simply there to help you create the most readable scenario.

The 2 scenarios below are the same from Cucumbers point of view.

Scenario: User attempts to log in with incorrect credentialsGiven I am displayed the log in formBut the login and password I enter are not validWhen I press the log in buttonThen I should not be allowed to log inAnd I should see a message informing that my credentials are not valid

Scenario: User attempts to log in with incorrect credentialsGiven I am displayed the log in formGIven the login and password I enter are not validWhen I press the log in buttonThen I should not be allowed to log inThen I should see a message informing that my credentials are not valid

State of a scenario

Each scenario must be capable of being run on its own and should not depend on data set up by other scenarios. This means every scenario has to include enough Given steps to set up all the data it needs.

Steps and Step DefinitionsScenarios describe what our tests should do, step definitions describe how to do it.

A step is just on line in the scenario, the step definition is its implementation.

Gherkin steps are expressed in plain text. Cucumber scans the text of each step for patterns that it recognizes, defined using a regular expression.

Capturing arguments

When surrounding a part of a regular expression with parentheses, it becomes a capture group. Capture groups are used to highlight particular parts of a pattern that you want to lift out of the matching text and use. In a Cucumber step definition, the text matched within each capture group is passed to the code block as an argument:

The dot is a metacharacter, means match any single character.Groovy syntax

Given I have deposited (...) in my Account { -> sumaDeBani

// code goes here

}

Ruby syntax

Given /^I have deposited "([^\"]*)" in my "([^\"]*)" Account$/ do |sum, accountType|

endGiven I have deposited 500 in my Account

Given I have deposited 600 in my Account

Given I have deposited 700 in my Account

Given I have deposited 900 in my Account

That will match a step with any three-figure string and send the matched amount into the block.

A repetition modifier takes a character (or metacharacter) and tells us how many times over it can appear.

The Plus Modifier means at least once:

Given I have deposited (.+) in my Account { -> sum

// code goes here

}

That will match a step with any string, at least once and send the matched amount into the block.

For a digit, we can use \d

The star modifier means any number of times. So, with .* were capturing any character, any number of times.

Given I have deposited (\d*) in my Account { -> sum

// code goes here

}

That will match a step with any digit, any number of time and send the matched amount into the block.

Multiple Captures

Given I have deposited (\d+) in my (\w+) { -> sum, account

// code goes here

}

The Background step

A background section in a feature file allows you to specify a set of steps that are common to every scenario in the file. Instead of having to repeat those steps over and over for each scenario, you move them up into a Background element.

There are a couple of advantages to doing this:

if you ever need to change those steps, you have to change them in only one place.

the importance of those steps fades into the background so that when youre reading each individual scenario, you can focus on what is unique and important about that scenario.

Feature: Change PIN

Customers being issued new cards are supplied with a Personal Identification Number (PIN) that is randomly generated by the system.

In order to be able to change it to something they can easily remember, customers with new bank cards need to be able to change their PIN using the ATM.

Scenario: Change PIN successfullyGiven I have been issued a new cardAnd I insert the card, entering the correct PINWhen I choose "Change PIN" from the menuAnd I change the PIN to 9876Then the system should remember my PIN is now 9876

Scenario: Try to change PIN to the same as beforeGiven I have been issued a new cardAnd I insert the card, entering the correct PINWhen I choose "Change PIN" from the menuAnd I try to change the PIN to the original PIN numberThen I should see a warning messageAnd the system should not have changed my PIN

Can be nicely written as followsFeature: Change PIN

..

Background:Given I have been issued a new cardAnd I insert the card, entering the correct PINAnd I choose "Change PIN" from the menu

Scenario: Change PIN successfullyWhen I change the PIN to 9876Then the system should remember my PIN is now 9876

Scenario: Try to change PIN to the same as beforeWhen I try to change the PIN to the original PIN numberThen I should see a warning messageAnd the system should not have changed my PIN

Scenario OutlineIt can be used when we have several scenarios that follow exactly the same pattern of steps, just with different input values or expected outcomes.

Feature: Withdraw Fixed Amount

The "Withdraw Cash" menu contains several fixed amounts to speed up transactions for users.

Scenario: Withdraw fixed amount of $50Given I have $500 in my accountWhen I choose to withdraw the fixed amount of $50Then I should receive $50 cashAnd the balance of my account should be $450

Scenario: Withdraw fixed amount of $100Given I have $500 in my accountWhen I choose to withdraw the fixed amount of $100Then I should receive $100 cashAnd the balance of my account should be $400

We can nicely write the scenarios using the scenario outline keyword

Scenario Outline: Withdraw fixed amountGiven I have in my accountWhen I choose to withdraw the fixed amount of Then I should receive cashAnd the balance of my account should be Examples:

| Balance | Withdrawal | Received | Remaining |

| $500 | $50 | $50 | $450 |

| $500 | $100 | $100 | $400 |

Using tagsTags are notes that we assign against scenarios or features. We create a tag by prefixing a word with the @ character:

@mytag1 @mytag2

Scenario: some functionality description

Given some initial context

When I trigger an event

Benefits of using tags:

- labeling the scenarios with an ID from a project management tool

- filtering the scenarios for running only a subset of the scenarios

- adding hooks to the tags

We can add specific hooks to a tag by using the Before and After methods in our step definitions layer.

Before(@mytag1) {

// code goes here

}

After(@mytag2) {

// code goes here

}

As a best practice we should use cucumber hooks to set up some initial context for that scenario and to tear down the configured data at the end of the scenario. (the best example is adding some data to the database before running a scenario and removing it after the scenario finishes)

Ruby syntax^ ----> beginning of a line or string $ ------> end of a line or string . -------> any character except newline s[ ] ------> any single character of set * -----> 0 or more previous regular expression

Global variables

Examples:

$foobar

$/

The variable which name begins with the character `$', has global scope, and can be accessed from any location of the program. Global variables are available as long as the program lives. Non-initialized global variables has value nil.

Instance variables

Examples:

@foobar

The variable which name begins which the character `@', is an instance variable of self. Instance variables are belong to the certain object. Non-initialized instance variables has value nil.