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 tags
Cucumber is a command-line tool. When you run it, it reads in your specifications from plainlanguage 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: 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 file
Feature: Search
Scenario: Display related articles
Given I am on the wikipedia homepage
When I click on the search field
And I enter in the search field Java programming language
And I click ok button
Then 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.
Feature
Each 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.
Scenario
To 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, Then
In Gherkin, we use the keywords Given, When, and Then to identify those three different parts of the
scenario.
And, But
Each 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 credentials

Given I am displayed the log in form
But the login and password I enter are not valid
When I press the log in button
Then I should not be allowed to log in
And I should see a message informing that my credentials are not valid
Scenario: User attempts to log in with incorrect credentials
Given I am displayed the log in form
GIven the login and password I enter are not valid
When I press the log in button
Then I should not be allowed to log in
Then 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 Definitions
Scenarios 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|
end
Given 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 successfully

Given I have been issued a new card
And I insert the card, entering the correct PIN
When I choose "Change PIN" from the menu
And I change the PIN to 9876
Then the system should remember my PIN is now 9876
Scenario: Try to change PIN to the same as before
Given I have been issued a new card
And I insert the card, entering the correct PIN
When I choose "Change PIN" from the menu
And I try to change the PIN to the original PIN number
Then I should see a warning message
And the system should not have changed my PIN
Can be nicely written as follows
Feature: Change PIN
..
Background:
Given I have been issued a new card
And I insert the card, entering the correct PIN
And I choose "Change PIN" from the menu
Scenario: Change PIN successfully
When I change the PIN to 9876
Then the system should remember my PIN is now 9876
Scenario: Try to change PIN to the same as before
When I try to change the PIN to the original PIN number
Then I should see a warning message
And the system should not have changed my PIN

Scenario Outline
It 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 $50
Given I have $500 in my account
When I choose to withdraw the fixed amount of $50
Then I should receive $50 cash
And the balance of my account should be $450
Scenario: Withdraw fixed amount of $100
Given I have $500 in my account
When I choose to withdraw the fixed amount of $100
Then I should receive $100 cash
And the balance of my account should be $400
We can nicely write the scenarios using the scenario outline keyword
Scenario Outline: Withdraw fixed amount
Given I have <Balance> in my account
When I choose to withdraw the fixed amount of <Withdrawal>
Then I should receive <Received> cash
And the balance of my account should be <Remaining>
Examples:
| Balance | Withdrawal | Received | Remaining |
| $500 | $50 | $50 | $450 |
| $500 | $100 | $100 | $400 |

Using tags
Tags 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.