Using Cucumber with Expertiza: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(9 intermediate revisions by the same user not shown)
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>


<code>
<pre>
    Feature: Impersonate User
  Feature: Impersonate User
        As an Administrator
    As an Administrator
        I should be able to impersonate users
    I should be able to impersonate users
</code>
</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>
<code>
<pre>
    Scenario: Impersonate a student as an Administrator
  Scenario: Impersonate a student as an Administrator
        Given an Administrator named "cucumber" exists
    Given an Administrator named "cucumber" exists
        And a Student named "impersonated_account" created by "cucumber" exists
    And a Student named "impersonated_account" created by "cucumber" exists
        When I log in as "cucumber"
    When I log in as "cucumber"
        And I click the menu link "Impersonate User"
    And I click the menu link "Impersonate User"
        And I fill in "user_name" with "impersonated_account"
    And I fill in "user_name" with "impersonated_account"
        When I press "Impersonate"
    When I press "Impersonate"
        Then I should be logged in as "impersonated_account"
    Then I should be logged in as "impersonated_account"
</code>
</pre>
<code>
<pre>
    Scenario: Impersonate a student that does not exist
  Scenario: Impersonate a student that does not exist
        Given an Administrator named "cucumber" exists
    Given an Administrator named "cucumber" exists
        When I log in as "cucumber"
    When I log in as "cucumber"
        And I click the menu link "Impersonate User"
    And I click the menu link "Impersonate User"
        And I fill in "user_name" with "impersonated_account"
    And I fill in "user_name" with "impersonated_account"
        When I press "Impersonate"
    When I press "Impersonate"
        Then I should see "No user exists with the name 'impersonated_account'"
    Then I should see "No user exists with the name 'impersonated_account'"
</code>
</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 50: Line 50:


===Step Definitions===
===Step Definitions===
Step defintions are written in the Capybara DSL and stored in the /features/step_definitions/ directory.
Cucumber will warn and skip Gherkin steps if they are not defined within a step definition file.


<pre>When /^I edit "([^"]*)" to have the name "([^"]*)"$/ do |arg1, arg2|
  pending # express the regexp above with the code you wish you had
end
</pre>
<pre>
Given /^there are other members of expertiza$/ do
  pending # express the regexp above with the code you wish you had
end
</pre>
For more information about writing step definitions. Check out the guide on [http://loudcoding.com/posts/quick-tutorial-starting-with-cucumber-and-capybara-bdd-on-rails-project/ Starting with Cucumber and Capybara].
==Running Cucumber==
==Running Cucumber==
===Setup===
Before running cucumber, make sure all necessary gems are installed by running
Setting up seeds
<pre>bundle install</pre>
Bundle install
Create the database and tables
Rake db:test:prepare
<pre>rake db:create</pre>
Cucumber decorators
Optionally prepare the test database
===Running Tests===
<pre>rake db:test:prepare</pre>
Run all features
=== Run all Features ===
Run a single feature
To run all cucumber features found within the /features directory
Run a single scenario
<pre>bundle exec cucumber</pre>
Undefined steps
=== Run a Single Feature ===
Sample output and what it means
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>
=== 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."
<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.
<pre>bundle exec cucumber features --name "Impersonate a student as an Administrator"</pre>
=== Run Tagged Features and/or Scenarios ===
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags 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 via command line or 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>
 
The output generated by this format is not very verbose.
Each character represents the status of each step<ref>The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers) [Matt Wynne, Aslak Hellesoy]</ref>:
* . means passing.
* U means undefined.
* - means skipped (or a Scenario Outline step).
* F means failing.
 
The following format 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>
<pre>std_opts = "--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip"</pre>
==References==
<references/>

Latest revision as of 16:52, 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

Step defintions are written in the Capybara DSL and stored in the /features/step_definitions/ directory. Cucumber will warn and skip Gherkin steps if they are not defined within a step definition file.

When /^I edit "([^"]*)" to have the name "([^"]*)"$/ do |arg1, arg2|
  pending # express the regexp above with the code you wish you had
end
Given /^there are other members of expertiza$/ do
  pending # express the regexp above with the code you wish you had
end

For more information about writing step definitions. Check out the guide on Starting with Cucumber and Capybara.

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 via command line or 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

The output generated by this format is not very verbose. Each character represents the status of each step<ref>The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers) [Matt Wynne, Aslak Hellesoy]</ref>:

  • . means passing.
  • U means undefined.
  • - means skipped (or a Scenario Outline step).
  • F means failing.

The following format 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"

References

<references/>