Using Cucumber with Expertiza: Difference between revisions
No edit summary |
No edit summary |
||
Line 67: | Line 67: | ||
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled "Impersonate a student as an Administrator." | You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled "Impersonate a student as an Administrator." | ||
<pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre> | <pre>bundle exec cucumber features/admin/impersonate_user.feature:5</pre> | ||
You can also specify several line numbers, allowing you to run several scenarios. | |||
<pre>cucumber features/admin/impersonate_user.feature:5:14</pre> | |||
Alternatively, you can specify the name of a scenario to run its instance. | Alternatively, you can specify the name of a scenario to run its instance. | ||
<pre>bundle exec cucumber features --name "Impersonate a student as an Administrator"</pre> | <pre>bundle exec cucumber features --name "Impersonate a student as an Administrator"</pre> | ||
Line 83: | Line 85: | ||
The current format set in cucumber.yml prints out each step of a scenario and colors it according to whether it passed, failed, was undefined or was skipped. | The current format set in cucumber.yml prints out each step of a scenario and colors it according to whether it passed, failed, was undefined or was skipped. | ||
This format provides you with the most information and is the one to use when working the red-green-refactor cycle.<ref>http://rubyflare.com/2010/02/05/cucumber-formatters/</ref> | |||
This format provides you with the most information and is the one to use when working the red-green-refactor cycle.</ref> | |||
<pre>std_opts = "--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip"</pre> | <pre>std_opts = "--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip"</pre> | ||
Other options exist, | Other options exist, |
Revision as of 16:24, 9 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
Run a Single Scenario
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled "Impersonate a student as an Administrator."
bundle exec cucumber features/admin/impersonate_user.feature:5
You can also specify several line numbers, allowing you to run several scenarios.
cucumber features/admin/impersonate_user.feature:5:14
Alternatively, you can specify the name of a scenario to run its instance.
bundle exec cucumber features --name "Impersonate a student as an Administrator"
Run Tagged Features and/or Scenarios
More information about running tests that share tags can be found in the Cucumber Wiki
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 Formatting
The output generated by cucumber can be formatted using decorators by modifying the std_opts variable in /config/cucumber.yml
These allow you to change the output from running tests in different ways. The default format is
cucumber --format progress
but it is not very verbose.
The current format set in cucumber.yml prints out each step of a scenario and colors it according to whether it passed, failed, was undefined or was skipped. This format provides you with the most information and is the one to use when working the red-green-refactor cycle.<ref>http://rubyflare.com/2010/02/05/cucumber-formatters/</ref>
std_opts = "--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip"
Other options exist,