Using Cucumber with Expertiza - Revision history

Pmocampo at 16:52, 9 February 2013

2013-02-09T16:52:53Z

← Older revision		Revision as of 16:52, 9 February 2013
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==
	Before running cucumber, make sure all necessary gems are installed by running		Before running cucumber, make sure all necessary gems are installed by running
Line 81:		Line 93:

	== Cucumber Formatting ==		== 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 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>		These allow you to change the output from running tests in different ways. The default format is <pre>cucumber --format progress</pre>

Line 91:		Line 103:
	* F means failing.		* F means failing.

	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 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>		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>		<pre>std_opts = "--format #{ENV['CUCUMBER_FORMAT'] \|\| 'pretty'} --strict --require features --tags ~@wip"</pre>
	==References==		==References==
	<references/>		<references/>

Pmocampo at 16:35, 9 February 2013

2013-02-09T16:35:12Z

← Older revision		Revision as of 16:35, 9 February 2013
Line 82:		Line 82:
	== Cucumber Formatting ==		== 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.		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 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.

Pmocampo at 16:26, 9 February 2013

2013-02-09T16:26:22Z

← Older revision		Revision as of 16:26, 9 February 2013
Line 87:		Line 87:
	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>http://rubyflare.com/2010/02/05/cucumber-formatters/</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,~~


	==References==		==References==
	<references/>		<references/>

Pmocampo at 16:25, 9 February 2013

2013-02-09T16:25:45Z

← Older revision		Revision as of 16:25, 9 February 2013
Line 87:		Line 87:
	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>http://rubyflare.com/2010/02/05/cucumber-formatters/</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,


			==References==
			<references/>

Pmocampo at 16:24, 9 February 2013

2013-02-09T16:24:19Z

← Older revision		Revision as of 16:24, 9 February 2013
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.
	~~<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>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,

Pmocampo at 16:17, 9 February 2013

2013-02-09T16:17:12Z

← Older revision		Revision as of 16:17, 9 February 2013
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.~~

Pmocampo: /* seeds.rb */

2013-02-09T00:01:47Z

seeds.rb

← Older revision		Revision as of 00:01, 9 February 2013
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 Decorators==
			The output generated by cucumber can be formatted using decorators by modifying the std_opts variable in /config/cucumber.yml
			<pre>std_opts = "--format #{ENV['CUCUMBER_FORMAT'] \|\| 'pretty'} --strict --require features --tags ~@wip"</pre>

			This enables clearer output of tests.

Pmocampo: /* Running Tests */

2013-02-08T23:55:22Z

Running Tests

← Older revision		Revision as of 23:55, 8 February 2013
Line 79:		Line 79:

	Cucumber decorators		Cucumber decorators
	~~===Running Tests===~~
	~~Run all features~~
	~~Run a single feature~~
	~~Run a single scenario~~
	~~Undefined steps~~
	~~Sample output and what it means~~

Pmocampo: /* Run a Single Feature */

2013-02-08T23:53:54Z

Run a Single Feature

← Older revision		Revision as of 23:53, 8 February 2013
Line 62:		Line 62:
	<pre>bundle exec cucumber</pre>		<pre>bundle exec cucumber</pre>
	=== Run a Single Feature ===		=== Run a Single Feature ===
	To run all scenarios for a single cucumber feature one must specify the feature file name		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>		<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>
			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===		===Environment Configuration===
	==== env.rb ====		==== env.rb ====

Pmocampo at 23:41, 8 February 2013

2013-02-08T23:41:04Z

← Older revision		Revision as of 23:41, 8 February 2013
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 52:		Line 52:

	==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>
			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===