Using Cucumber with Expertiza: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
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 Decorators==
== 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,
This enables clearer output of tests.

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,