Using Cucumber with Expertiza: Difference between revisions
No edit summary |
|||
Line 78: | Line 78: | ||
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb | The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb | ||
== Cucumber | == Cucumber Formatting == | ||
The output generated by cucumber can be formatted using decorators by modifying the std_opts variable in /config/cucumber.yml | 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 <pre>cucumber --format progress</pre> 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. | |||
<ref=http://rubyflare.com/2010/02/05/cucumber-formatters/> | |||
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, | |||
Revision as of 16:17, 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
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.
<ref=http://rubyflare.com/2010/02/05/cucumber-formatters/>
This format provides you with the most information and is the one to use when working the red-green-refactor cycle.</ref>
std_opts = "--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip"
Other options exist,