Features
A feature is rarely defined by specific behavior. For this very reason, Scenarios can be grouped together logically under a Feature Definition. Feature definitions are typically given a name and an optional short description. For example:
Feature: Test the entire app
Scenario: Log in to app
Given my app is running
Then I take a picture
Then I use the native keyboard to enter “username@domain.com” into the “your name” text field
Then I use the native keyboard to enter “myPassword123” into the “password” text field
Then I press "Sign In"
Scenario: As a valid user I can start using the app
I wait for text "Hello"
Then I wait for activity "HomeTabActivity"
Then I press the view with id "menu_compose_tweet"
Then I enter text "BitBar Testing" into the field with id "edit"
Then I press the view with id "composer_post"
Steps and step definitions
Step definitions are like code-behind for the scenarios defined in step definition scrips. They provide the glue that makes them runnable in the application. Their function is to translate readable text into runnable actions.
Scenarios
A scenario specifies single behavior or use case within a given feature that is comprised of various Steps. For example, the following scenario describes the behavior of ensuring that a credit card input field has the correct length of digits:
Scenario: Run whole app
Given my app is running
And I touch the "Start" button
Then I take a picture
Then I press "More Info"
Steps usually begin with one of the keywords: Given, When, Then, And, and But. However, they don’t have to - they can use * in place of those keywords. In fact, Cucumber does not distinguish between them (or *). They are instead meant to provide a language hint based on the cause and effect to the stakeholders as to what is being described.
As such, simply recognizing their language implications is enough to use them effectively. However, for a detailed examination of these keywords, see the Cucumber Wiki entry on them.