Using Cucumber with Expertiza: Difference between revisions
No edit summary |
No edit summary |
||
Line 10: | Line 10: | ||
A feature is written in an explanatory syntax called [https://github.com/cucumber/cucumber/wiki/Gherkin Gherkin]. For the Impersonate User feature, a feature would be described as.</p> | A feature is written in an explanatory syntax called [https://github.com/cucumber/cucumber/wiki/Gherkin Gherkin]. For the Impersonate User feature, a feature would be described as.</p> | ||
< | <pre> | ||
Feature: Impersonate User | |||
As an Administrator | |||
I should be able to impersonate users | |||
</ | </pre> | ||
===Scenarios=== | ===Scenarios=== | ||
<p>Each feature file can contain multiple scenarios. This is to test the same feature in different ways using the [https://github.com/cucumber/cucumber/wiki/Given-When-Then Given-When-Then structure]. For example. An administrator should be able to impersonate an existing student, but he should not be able to impersonate a student that doesn't exist. In the case of an instructor, he should only be able to impersonate students that are in his class.</p> | <p>Each feature file can contain multiple scenarios. This is to test the same feature in different ways using the [https://github.com/cucumber/cucumber/wiki/Given-When-Then Given-When-Then structure]. For example. An administrator should be able to impersonate an existing student, but he should not be able to impersonate a student that doesn't exist. In the case of an instructor, he should only be able to impersonate students that are in his class.</p> | ||
< | <pre> | ||
Scenario: Impersonate a student as an Administrator | |||
Given an Administrator named "cucumber" exists | |||
And a Student named "impersonated_account" created by "cucumber" exists | |||
When I log in as "cucumber" | |||
And I click the menu link "Impersonate User" | |||
And I fill in "user_name" with "impersonated_account" | |||
When I press "Impersonate" | |||
Then I should be logged in as "impersonated_account" | |||
</ | </pre> | ||
< | <pre> | ||
Scenario: Impersonate a student that does not exist | |||
Given an Administrator named "cucumber" exists | |||
When I log in as "cucumber" | |||
And I click the menu link "Impersonate User" | |||
And I fill in "user_name" with "impersonated_account" | |||
When I press "Impersonate" | |||
Then I should see "No user exists with the name 'impersonated_account'" | |||
</ | </pre> | ||
<p>Gherkin provides multiple keywords to describe steps in a scenario such as:</p> | <p>Gherkin provides multiple keywords to describe steps in a scenario such as:</p> | ||
* Feature | * Feature | ||
Line 52: | Line 52: | ||
==Running Cucumber== | ==Running Cucumber== | ||
=== | Before running cucumber, make sure all necessary gems are installed by running | ||
<pre>bundle install</pre> | |||
Create the database and tables | |||
<pre>rake db:create</pre> | |||
Optionally prepare the test database | |||
<pre>rake db:test:prepare</pre> | |||
=== Run all Features === | |||
To run all cucumber features found within the /features directory | |||
<pre>bundle exec cucumber</pre> | |||
=== Run a Single Feature === | |||
To run all scenarios for a single cucumber feature one must specify the feature file name | |||
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre> | |||
Alternatively, you can run a feature by specifying it's descriptor | |||
<pre>bundle exec cucumber features/admin/impersonate_user.feature</pre> | |||
===Environment Configuration=== | |||
==== env.rb ==== | |||
Cucumber configuration variables can be edited in /features/support/env.rb | |||
==== seeds.rb ==== | |||
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb | |||
Cucumber decorators | Cucumber decorators | ||
===Running Tests=== | ===Running Tests=== |
Revision as of 23:41, 8 February 2013
Cucumber Stack
Features
Features provide a brief description about the functionality being tested.
In Expertiza, features are stored in /features. Within this folder you can find several sub-folders such as /admin, /instructor, and /student. This structure is to organize tests that apply to specific roles.
Each .feature file tests a specific aspect of the system, such as an Administrator's ability to Impersonate a User. (/features/admin/impersonate_user.feature) A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.
Feature: Impersonate User As an Administrator I should be able to impersonate users
Scenarios
Each feature file can contain multiple scenarios. This is to test the same feature in different ways using the Given-When-Then structure. For example. An administrator should be able to impersonate an existing student, but he should not be able to impersonate a student that doesn't exist. In the case of an instructor, he should only be able to impersonate students that are in his class.
Scenario: Impersonate a student as an Administrator Given an Administrator named "cucumber" exists And a Student named "impersonated_account" created by "cucumber" exists When I log in as "cucumber" And I click the menu link "Impersonate User" And I fill in "user_name" with "impersonated_account" When I press "Impersonate" Then I should be logged in as "impersonated_account"
Scenario: Impersonate a student that does not exist Given an Administrator named "cucumber" exists When I log in as "cucumber" And I click the menu link "Impersonate User" And I fill in "user_name" with "impersonated_account" When I press "Impersonate" Then I should see "No user exists with the name 'impersonated_account'"
Gherkin provides multiple keywords to describe steps in a scenario such as:
- Feature
- Background
- Scenario
- Given
- When
- Then
- And
- But
- Scenario Outline
- Examples
Step Definitions
Running Cucumber
Before running cucumber, make sure all necessary gems are installed by running
bundle install
Create the database and tables
rake db:create
Optionally prepare the test database
rake db:test:prepare
Run all Features
To run all cucumber features found within the /features directory
bundle exec cucumber
Run a Single Feature
To run all scenarios for a single cucumber feature one must specify the feature file name
bundle exec cucumber features/admin/impersonate_user.feature
Alternatively, you can run a feature by specifying it's descriptor
bundle exec cucumber features/admin/impersonate_user.feature
Environment Configuration
env.rb
Cucumber configuration variables can be edited in /features/support/env.rb
seeds.rb
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb
Cucumber decorators
Running Tests
Run all features Run a single feature Run a single scenario Undefined steps Sample output and what it means