<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Pmocampo</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Pmocampo"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Pmocampo"/>
	<updated>2026-05-13T13:51:14Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74927</id>
		<title>Expertiza Continuous Integration</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74927"/>
		<updated>2013-04-17T19:55:00Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Benefits */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The build status for the Expertiza project is tracked by the [[http://about.travis-ci.org/blog/ Travis Continuous Integration]] tool.&lt;br /&gt;
You can see the current status of the project using the [[https://travis-ci.org/expertiza/expertiza Expertiza Travis Dashboard]]&lt;br /&gt;
== Continuous Integration ==&lt;br /&gt;
Travis CI automatically builds the Expertiza project to make sure that no failures are introduced into the existing test suites after new code is committed.&lt;br /&gt;
As of April 18th, 2013, the Travis CI configuration for Expertiza only builds and checks the cucumber test suite for failures on the master and production branches.&lt;br /&gt;
== Benefits ==&lt;br /&gt;
* Notifies the Expertiza Support List of test failures or changes in a build (previously failing tests passing after a build).&lt;br /&gt;
* Build status indicator on the Expertiza [[https://github.com/expertiza/expertiza/blob/master/README.md Github readme]].&lt;br /&gt;
* Pass/Fail indicator on pull requests and a link to a Travis summary specific to that build request.&lt;br /&gt;
[[File:Screen_Shot_2013-04-17_at_3.38.47_PM.png]]&lt;br /&gt;
* Allows Expertiza contributors to determine whether a pull request is admissible before merging the code&lt;br /&gt;
* Allows Expertiza contributors to catch a build failure and roll back a commit.&lt;br /&gt;
&lt;br /&gt;
== Travis CI Build Configuration ==&lt;br /&gt;
The [[http://about.travis-ci.org/docs/user/build-configuration/ configuration documentation]] for Travis is very extensive but there are some things to note in regards to Expertiza.&lt;br /&gt;
Configuration changes are done by modifying the [[https://github.com/expertiza/expertiza/blob/master/.travis.yml .travis.yml]] configuration file in the root of the repository and committing to the master and/or production branch.&lt;br /&gt;
&lt;br /&gt;
* Additional branches can be included in build inspections by adding their names to the list under &amp;lt;i&amp;gt;branches&amp;lt;/i&amp;gt;&lt;br /&gt;
* Email notifications can be modified by including additional recipients or changing the [[http://about.travis-ci.org/docs/user/notifications/#Email-notifications frequency of notifications]]&lt;br /&gt;
* To include rspec tests into the build inspection, we must add the following line of code in the &amp;lt;i&amp;gt;script&amp;lt;/i&amp;gt; block&lt;br /&gt;
&amp;lt;code&amp;gt;- &amp;quot;export DISPLAY=:99.0 &amp;amp;&amp;amp; bundle exec rspec spec/&amp;quot;&amp;lt;/code&amp;gt;&lt;br /&gt;
* A specific cucumber formatter for Travis exists and it can be modified by editing the &amp;lt;i&amp;gt;travis&amp;lt;/i&amp;gt; profile in [[https://github.com/expertiza/expertiza/blob/master/config/cucumber.yml cucumber.yml]]&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74926</id>
		<title>Expertiza Continuous Integration</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74926"/>
		<updated>2013-04-17T19:54:45Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Benefits */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The build status for the Expertiza project is tracked by the [[http://about.travis-ci.org/blog/ Travis Continuous Integration]] tool.&lt;br /&gt;
You can see the current status of the project using the [[https://travis-ci.org/expertiza/expertiza Expertiza Travis Dashboard]]&lt;br /&gt;
== Continuous Integration ==&lt;br /&gt;
Travis CI automatically builds the Expertiza project to make sure that no failures are introduced into the existing test suites after new code is committed.&lt;br /&gt;
As of April 18th, 2013, the Travis CI configuration for Expertiza only builds and checks the cucumber test suite for failures on the master and production branches.&lt;br /&gt;
== Benefits ==&lt;br /&gt;
* Notifies the Expertiza Support List of test failures or changes in a build (previously failing tests passing after a build).&lt;br /&gt;
* Build status indicator on the Expertiza [[https://github.com/expertiza/expertiza/blob/master/README.md Github readme]].&lt;br /&gt;
* Pass/Fail indicator on pull requests and a link to a Travis summary specific to that build request.&lt;br /&gt;
[[Screen_Shot_2013-04-17_at_3.38.47_PM.png]]&lt;br /&gt;
* Allows Expertiza contributors to determine whether a pull request is admissible before merging the code&lt;br /&gt;
* Allows Expertiza contributors to catch a build failure and roll back a commit.&lt;br /&gt;
&lt;br /&gt;
== Travis CI Build Configuration ==&lt;br /&gt;
The [[http://about.travis-ci.org/docs/user/build-configuration/ configuration documentation]] for Travis is very extensive but there are some things to note in regards to Expertiza.&lt;br /&gt;
Configuration changes are done by modifying the [[https://github.com/expertiza/expertiza/blob/master/.travis.yml .travis.yml]] configuration file in the root of the repository and committing to the master and/or production branch.&lt;br /&gt;
&lt;br /&gt;
* Additional branches can be included in build inspections by adding their names to the list under &amp;lt;i&amp;gt;branches&amp;lt;/i&amp;gt;&lt;br /&gt;
* Email notifications can be modified by including additional recipients or changing the [[http://about.travis-ci.org/docs/user/notifications/#Email-notifications frequency of notifications]]&lt;br /&gt;
* To include rspec tests into the build inspection, we must add the following line of code in the &amp;lt;i&amp;gt;script&amp;lt;/i&amp;gt; block&lt;br /&gt;
&amp;lt;code&amp;gt;- &amp;quot;export DISPLAY=:99.0 &amp;amp;&amp;amp; bundle exec rspec spec/&amp;quot;&amp;lt;/code&amp;gt;&lt;br /&gt;
* A specific cucumber formatter for Travis exists and it can be modified by editing the &amp;lt;i&amp;gt;travis&amp;lt;/i&amp;gt; profile in [[https://github.com/expertiza/expertiza/blob/master/config/cucumber.yml cucumber.yml]]&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74925</id>
		<title>Expertiza Continuous Integration</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74925"/>
		<updated>2013-04-17T19:54:31Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Benefits */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The build status for the Expertiza project is tracked by the [[http://about.travis-ci.org/blog/ Travis Continuous Integration]] tool.&lt;br /&gt;
You can see the current status of the project using the [[https://travis-ci.org/expertiza/expertiza Expertiza Travis Dashboard]]&lt;br /&gt;
== Continuous Integration ==&lt;br /&gt;
Travis CI automatically builds the Expertiza project to make sure that no failures are introduced into the existing test suites after new code is committed.&lt;br /&gt;
As of April 18th, 2013, the Travis CI configuration for Expertiza only builds and checks the cucumber test suite for failures on the master and production branches.&lt;br /&gt;
== Benefits ==&lt;br /&gt;
* Notifies the Expertiza Support List of test failures or changes in a build (previously failing tests passing after a build).&lt;br /&gt;
* Build status indicator on the Expertiza [[https://github.com/expertiza/expertiza/blob/master/README.md Github readme]].&lt;br /&gt;
* Pass/Fail indicator on pull requests and a link to a Travis summary specific to that build request.&lt;br /&gt;
[[http://wiki.expertiza.ncsu.edu/index.php/File:Screen_Shot_2013-04-17_at_3.38.47_PM.png]]&lt;br /&gt;
* Allows Expertiza contributors to determine whether a pull request is admissible before merging the code&lt;br /&gt;
* Allows Expertiza contributors to catch a build failure and roll back a commit.&lt;br /&gt;
&lt;br /&gt;
== Travis CI Build Configuration ==&lt;br /&gt;
The [[http://about.travis-ci.org/docs/user/build-configuration/ configuration documentation]] for Travis is very extensive but there are some things to note in regards to Expertiza.&lt;br /&gt;
Configuration changes are done by modifying the [[https://github.com/expertiza/expertiza/blob/master/.travis.yml .travis.yml]] configuration file in the root of the repository and committing to the master and/or production branch.&lt;br /&gt;
&lt;br /&gt;
* Additional branches can be included in build inspections by adding their names to the list under &amp;lt;i&amp;gt;branches&amp;lt;/i&amp;gt;&lt;br /&gt;
* Email notifications can be modified by including additional recipients or changing the [[http://about.travis-ci.org/docs/user/notifications/#Email-notifications frequency of notifications]]&lt;br /&gt;
* To include rspec tests into the build inspection, we must add the following line of code in the &amp;lt;i&amp;gt;script&amp;lt;/i&amp;gt; block&lt;br /&gt;
&amp;lt;code&amp;gt;- &amp;quot;export DISPLAY=:99.0 &amp;amp;&amp;amp; bundle exec rspec spec/&amp;quot;&amp;lt;/code&amp;gt;&lt;br /&gt;
* A specific cucumber formatter for Travis exists and it can be modified by editing the &amp;lt;i&amp;gt;travis&amp;lt;/i&amp;gt; profile in [[https://github.com/expertiza/expertiza/blob/master/config/cucumber.yml cucumber.yml]]&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Screen_Shot_2013-04-17_at_3.38.47_PM.png&amp;diff=74924</id>
		<title>File:Screen Shot 2013-04-17 at 3.38.47 PM.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Screen_Shot_2013-04-17_at_3.38.47_PM.png&amp;diff=74924"/>
		<updated>2013-04-17T19:53:25Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: Travis Pull Request&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Travis Pull Request&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74923</id>
		<title>Expertiza Continuous Integration</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74923"/>
		<updated>2013-04-17T19:52:40Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Travis CI Build Configuration */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The build status for the Expertiza project is tracked by the [[http://about.travis-ci.org/blog/ Travis Continuous Integration]] tool.&lt;br /&gt;
You can see the current status of the project using the [[https://travis-ci.org/expertiza/expertiza Expertiza Travis Dashboard]]&lt;br /&gt;
== Continuous Integration ==&lt;br /&gt;
Travis CI automatically builds the Expertiza project to make sure that no failures are introduced into the existing test suites after new code is committed.&lt;br /&gt;
As of April 18th, 2013, the Travis CI configuration for Expertiza only builds and checks the cucumber test suite for failures on the master and production branches.&lt;br /&gt;
== Benefits ==&lt;br /&gt;
* Notifies the Expertiza Support List of test failures or changes in a build (previously failing tests passing after a build).&lt;br /&gt;
* Build status indicator on the Expertiza [[https://github.com/expertiza/expertiza/blob/master/README.md Github readme]].&lt;br /&gt;
* Pass/Fail indicator on pull requests and a link to a Travis summary specific to that build request.&lt;br /&gt;
* Allows Expertiza contributors to determine whether a pull request is admissible before merging the code&lt;br /&gt;
* Allows Expertiza contributors to catch a build failure and roll back a commit.&lt;br /&gt;
== Travis CI Build Configuration ==&lt;br /&gt;
The [[http://about.travis-ci.org/docs/user/build-configuration/ configuration documentation]] for Travis is very extensive but there are some things to note in regards to Expertiza.&lt;br /&gt;
Configuration changes are done by modifying the [[https://github.com/expertiza/expertiza/blob/master/.travis.yml .travis.yml]] configuration file in the root of the repository and committing to the master and/or production branch.&lt;br /&gt;
&lt;br /&gt;
* Additional branches can be included in build inspections by adding their names to the list under &amp;lt;i&amp;gt;branches&amp;lt;/i&amp;gt;&lt;br /&gt;
* Email notifications can be modified by including additional recipients or changing the [[http://about.travis-ci.org/docs/user/notifications/#Email-notifications frequency of notifications]]&lt;br /&gt;
* To include rspec tests into the build inspection, we must add the following line of code in the &amp;lt;i&amp;gt;script&amp;lt;/i&amp;gt; block&lt;br /&gt;
&amp;lt;code&amp;gt;- &amp;quot;export DISPLAY=:99.0 &amp;amp;&amp;amp; bundle exec rspec spec/&amp;quot;&amp;lt;/code&amp;gt;&lt;br /&gt;
* A specific cucumber formatter for Travis exists and it can be modified by editing the &amp;lt;i&amp;gt;travis&amp;lt;/i&amp;gt; profile in [[https://github.com/expertiza/expertiza/blob/master/config/cucumber.yml cucumber.yml]]&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74922</id>
		<title>Expertiza Continuous Integration</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74922"/>
		<updated>2013-04-17T19:44:08Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The build status for the Expertiza project is tracked by the [[http://about.travis-ci.org/blog/ Travis Continuous Integration]] tool.&lt;br /&gt;
You can see the current status of the project using the [[https://travis-ci.org/expertiza/expertiza Expertiza Travis Dashboard]]&lt;br /&gt;
== Continuous Integration ==&lt;br /&gt;
Travis CI automatically builds the Expertiza project to make sure that no failures are introduced into the existing test suites after new code is committed.&lt;br /&gt;
As of April 18th, 2013, the Travis CI configuration for Expertiza only builds and checks the cucumber test suite for failures on the master and production branches.&lt;br /&gt;
== Benefits ==&lt;br /&gt;
* Notifies the Expertiza Support List of test failures or changes in a build (previously failing tests passing after a build).&lt;br /&gt;
* Build status indicator on the Expertiza [[https://github.com/expertiza/expertiza/blob/master/README.md Github readme]].&lt;br /&gt;
* Pass/Fail indicator on pull requests and a link to a Travis summary specific to that build request.&lt;br /&gt;
* Allows Expertiza contributors to determine whether a pull request is admissible before merging the code&lt;br /&gt;
* Allows Expertiza contributors to catch a build failure and roll back a commit.&lt;br /&gt;
== Travis CI Build Configuration ==&lt;br /&gt;
The [[http://about.travis-ci.org/docs/user/build-configuration/ configuration documentation]] for Travis is very extensive but there are some things to note in regards to Expertiza.&lt;br /&gt;
Configuration changes are done by modifying the .travis.yml configuration file in the root of the repository and committing to the master and/or production branch.&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74921</id>
		<title>Expertiza Continuous Integration</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Expertiza_Continuous_Integration&amp;diff=74921"/>
		<updated>2013-04-17T19:31:57Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: Created page with &amp;quot;The build status for the Expertiza project is tracked by the http://about.travis-ci.org/blog/ Travis Continuous Integration tool. You can see the current status of the projec...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The build status for the Expertiza project is tracked by the [[http://about.travis-ci.org/blog/ Travis Continuous Integration]] tool.&lt;br /&gt;
You can see the current status of the project using the [[https://travis-ci.org/expertiza/expertiza Expertiza Travis Dashboard]]&lt;br /&gt;
== Continuous Integration ==&lt;br /&gt;
== Benefits ==&lt;br /&gt;
== Travis CI Build Configuration ==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=MainPage&amp;diff=74920</id>
		<title>MainPage</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=MainPage&amp;diff=74920"/>
		<updated>2013-04-17T19:26:08Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Testing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Course-Specific Topics==&lt;br /&gt;
* [[CSC 216]] learning exercise&lt;br /&gt;
* [[CSC 379]]&lt;br /&gt;
* [[CSC/ECE 506 Fall 2007]]&lt;br /&gt;
* [[ECE506_Main_Page | CSC/ECE 506 Main Portal]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2007]]&lt;br /&gt;
* [[CSC/ECE 517 Summer 2008]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2010]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2011]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2012]]&lt;br /&gt;
* [[CSC 456 Spring 2011|CSC 456 Spring 2012]]&lt;br /&gt;
* [[ECE 633]]&lt;br /&gt;
* [[KCU]]&lt;br /&gt;
* [[Progress reports]]&lt;br /&gt;
&lt;br /&gt;
==Application Behavior==&lt;br /&gt;
* [[Grading]]&lt;br /&gt;
&lt;br /&gt;
==Metaprogramming==&lt;br /&gt;
* [[CSC/ECE_517_Spring_2013/ch1b_1k_hf|Lecture on Metaprogramming]]&lt;br /&gt;
&lt;br /&gt;
==Development==&lt;br /&gt;
&lt;br /&gt;
''Expertiza now has a Java dependency, so the machine you are using to develop Expertiza on should have the JVM installed.''&lt;br /&gt;
&lt;br /&gt;
* [[Setting Up a Development Machine]]&lt;br /&gt;
* [[Creating a Linux Development Environment for Expertiza - Installation Guide]]&lt;br /&gt;
* [[Using git and github for projects]]&lt;br /&gt;
* [[Using heroku to deploy your projects]]&lt;br /&gt;
* [[How to Begin a Project from the Current Expertiza Repository]]&lt;br /&gt;
* [[Git]]&lt;br /&gt;
&lt;br /&gt;
==Production==&lt;br /&gt;
* [[Deploying to Production]]&lt;br /&gt;
* [[Accessing the Production Server]]&lt;br /&gt;
&lt;br /&gt;
==Testing==&lt;br /&gt;
* [[Using Cucumber with Expertiza]]&lt;br /&gt;
* [[Rails Testing Overview]]&lt;br /&gt;
* [[Expertiza Continuous Integration]]&lt;br /&gt;
&lt;br /&gt;
==Design==&lt;br /&gt;
* [[Object-Oriented Design and Programming]]&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=MainPage&amp;diff=73874</id>
		<title>MainPage</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=MainPage&amp;diff=73874"/>
		<updated>2013-03-12T19:05:11Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Development */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Course-Specific Topics==&lt;br /&gt;
* [[CSC 216]] learning exercise&lt;br /&gt;
* [[CSC 379]]&lt;br /&gt;
* [[CSC/ECE 506 Fall 2007]]&lt;br /&gt;
* [[ECE506_Main_Page | CSC/ECE 506 Main Portal]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2007]]&lt;br /&gt;
* [[CSC/ECE 517 Summer 2008]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2010]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2011]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2012]]&lt;br /&gt;
* [[CSC 456 Spring 2011|CSC 456 Spring 2012]]&lt;br /&gt;
* [[ECE 633]]&lt;br /&gt;
* [[KCU]]&lt;br /&gt;
* [[Progress reports]]&lt;br /&gt;
&lt;br /&gt;
==Application Behavior==&lt;br /&gt;
* [[Grading]]&lt;br /&gt;
&lt;br /&gt;
==Metaprogramming==&lt;br /&gt;
* [[CSC/ECE_517_Spring_2013/ch1b_1k_hf|Lecture on Metaprogramming]]&lt;br /&gt;
&lt;br /&gt;
==Development==&lt;br /&gt;
&lt;br /&gt;
''Expertiza now has a Java dependency, so the machine you are using to develop Expertiza on should have the JVM installed.''&lt;br /&gt;
&lt;br /&gt;
* [[Setting Up a Development Machine]]&lt;br /&gt;
* [[Creating a Linux Development Environment for Expertiza - Installation Guide]]&lt;br /&gt;
* [[Using git and github for projects]]&lt;br /&gt;
* [[Using heroku to deploy your projects]]&lt;br /&gt;
* [[How to Begin a Project from the Current Expertiza Repository]]&lt;br /&gt;
&lt;br /&gt;
==Production==&lt;br /&gt;
* [[Deploying to Production]]&lt;br /&gt;
* [[Accessing the Production Server]]&lt;br /&gt;
&lt;br /&gt;
==Testing==&lt;br /&gt;
* [[Using Cucumber with Expertiza]]&lt;br /&gt;
* [[Rails Testing Overview]]&lt;br /&gt;
&lt;br /&gt;
==Design==&lt;br /&gt;
* [[Object-Oriented Design and Programming]]&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=MainPage&amp;diff=73873</id>
		<title>MainPage</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=MainPage&amp;diff=73873"/>
		<updated>2013-03-12T19:04:54Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Development */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Course-Specific Topics==&lt;br /&gt;
* [[CSC 216]] learning exercise&lt;br /&gt;
* [[CSC 379]]&lt;br /&gt;
* [[CSC/ECE 506 Fall 2007]]&lt;br /&gt;
* [[ECE506_Main_Page | CSC/ECE 506 Main Portal]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2007]]&lt;br /&gt;
* [[CSC/ECE 517 Summer 2008]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2010]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2011]]&lt;br /&gt;
* [[CSC/ECE 517 Fall 2012]]&lt;br /&gt;
* [[CSC 456 Spring 2011|CSC 456 Spring 2012]]&lt;br /&gt;
* [[ECE 633]]&lt;br /&gt;
* [[KCU]]&lt;br /&gt;
* [[Progress reports]]&lt;br /&gt;
&lt;br /&gt;
==Application Behavior==&lt;br /&gt;
* [[Grading]]&lt;br /&gt;
&lt;br /&gt;
==Metaprogramming==&lt;br /&gt;
* [[CSC/ECE_517_Spring_2013/ch1b_1k_hf|Lecture on Metaprogramming]]&lt;br /&gt;
&lt;br /&gt;
==Development==&lt;br /&gt;
&lt;br /&gt;
''Expertiza now has a Java dependency, so the machine you are using to develop Expertiza on should have the JVM installed.''&lt;br /&gt;
&lt;br /&gt;
* [[Setting Up a Development Machine]]&lt;br /&gt;
* [[Creating a Linux Development Environment for Expertiza - Installation Guide]]&lt;br /&gt;
* [[Using git and github for projects]]&lt;br /&gt;
* [[Using heroku to deploy your projects]]&lt;br /&gt;
* [[How to Begin a Project from the Current Expertiza Repository]]&lt;br /&gt;
* [[Using Cucumber with Expertiza]]&lt;br /&gt;
&lt;br /&gt;
==Production==&lt;br /&gt;
* [[Deploying to Production]]&lt;br /&gt;
* [[Accessing the Production Server]]&lt;br /&gt;
&lt;br /&gt;
==Testing==&lt;br /&gt;
* [[Using Cucumber with Expertiza]]&lt;br /&gt;
* [[Rails Testing Overview]]&lt;br /&gt;
&lt;br /&gt;
==Design==&lt;br /&gt;
* [[Object-Oriented Design and Programming]]&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72281</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72281"/>
		<updated>2013-02-09T16:52:53Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
Step defintions are written in the Capybara DSL and stored in the /features/step_definitions/ directory.&lt;br /&gt;
Cucumber will warn and skip Gherkin steps if they are not defined within a step definition file.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;When /^I edit &amp;quot;([^&amp;quot;]*)&amp;quot; to have the name &amp;quot;([^&amp;quot;]*)&amp;quot;$/ do |arg1, arg2|&lt;br /&gt;
  pending # express the regexp above with the code you wish you had&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Given /^there are other members of expertiza$/ do&lt;br /&gt;
  pending # express the regexp above with the code you wish you had&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
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]. &lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name. &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Scenario ===&lt;br /&gt;
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled &amp;quot;Impersonate a student as an Administrator.&amp;quot;&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature:5&amp;lt;/pre&amp;gt;&lt;br /&gt;
You can also specify several line numbers, allowing you to run several scenarios. &lt;br /&gt;
&amp;lt;pre&amp;gt;cucumber features/admin/impersonate_user.feature:5:14&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can specify the name of a scenario to run its instance.&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features --name &amp;quot;Impersonate a student as an Administrator&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run Tagged Features and/or Scenarios ===&lt;br /&gt;
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags Cucumber Wiki]&lt;br /&gt;
&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
== Cucumber Formatting ==&lt;br /&gt;
The output generated by cucumber can be formatted via command line or by modifying the std_opts variable in /config/cucumber.yml&lt;br /&gt;
These allow you to change the output from running tests in different ways. The default format is &amp;lt;pre&amp;gt;cucumber --format progress&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The output generated by this format is not very verbose.&lt;br /&gt;
Each character represents the status of each step&amp;lt;ref&amp;gt;The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers) [Matt Wynne, Aslak Hellesoy]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
* . means passing.&lt;br /&gt;
* U means undefined.&lt;br /&gt;
* - means skipped (or a Scenario Outline step). &lt;br /&gt;
* F means failing.&lt;br /&gt;
&lt;br /&gt;
The following format prints out each step of a scenario and colors it according to whether it passed, failed, was undefined or was skipped. &lt;br /&gt;
This format provides you with the most information and is the one to use when working the red-green-refactor cycle.&amp;lt;ref&amp;gt;http://rubyflare.com/2010/02/05/cucumber-formatters/&amp;lt;/ref&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;std_opts = &amp;quot;--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72280</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72280"/>
		<updated>2013-02-09T16:35:12Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name. &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Scenario ===&lt;br /&gt;
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled &amp;quot;Impersonate a student as an Administrator.&amp;quot;&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature:5&amp;lt;/pre&amp;gt;&lt;br /&gt;
You can also specify several line numbers, allowing you to run several scenarios. &lt;br /&gt;
&amp;lt;pre&amp;gt;cucumber features/admin/impersonate_user.feature:5:14&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can specify the name of a scenario to run its instance.&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features --name &amp;quot;Impersonate a student as an Administrator&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run Tagged Features and/or Scenarios ===&lt;br /&gt;
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags Cucumber Wiki]&lt;br /&gt;
&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
== Cucumber Formatting ==&lt;br /&gt;
The output generated by cucumber can be formatted using decorators by modifying the std_opts variable in /config/cucumber.yml&lt;br /&gt;
These allow you to change the output from running tests in different ways. The default format is &amp;lt;pre&amp;gt;cucumber --format progress&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The output generated by this format is not very verbose.&lt;br /&gt;
Each character represents the status of each step&amp;lt;ref&amp;gt;The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers) [Matt Wynne, Aslak Hellesoy]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
* . means passing.&lt;br /&gt;
* U means undefined.&lt;br /&gt;
* - means skipped (or a Scenario Outline step). &lt;br /&gt;
* F means failing.&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
This format provides you with the most information and is the one to use when working the red-green-refactor cycle.&amp;lt;ref&amp;gt;http://rubyflare.com/2010/02/05/cucumber-formatters/&amp;lt;/ref&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;std_opts = &amp;quot;--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72279</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72279"/>
		<updated>2013-02-09T16:26:22Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name. &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Scenario ===&lt;br /&gt;
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled &amp;quot;Impersonate a student as an Administrator.&amp;quot;&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature:5&amp;lt;/pre&amp;gt;&lt;br /&gt;
You can also specify several line numbers, allowing you to run several scenarios. &lt;br /&gt;
&amp;lt;pre&amp;gt;cucumber features/admin/impersonate_user.feature:5:14&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can specify the name of a scenario to run its instance.&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features --name &amp;quot;Impersonate a student as an Administrator&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run Tagged Features and/or Scenarios ===&lt;br /&gt;
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags Cucumber Wiki]&lt;br /&gt;
&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
== Cucumber Formatting ==&lt;br /&gt;
The output generated by cucumber can be formatted using decorators by modifying the std_opts variable in /config/cucumber.yml&lt;br /&gt;
These allow you to change the output from running tests in different ways. The default format is &amp;lt;pre&amp;gt;cucumber --format progress&amp;lt;/pre&amp;gt; but it is not very verbose. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
This format provides you with the most information and is the one to use when working the red-green-refactor cycle.&amp;lt;ref&amp;gt;http://rubyflare.com/2010/02/05/cucumber-formatters/&amp;lt;/ref&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;std_opts = &amp;quot;--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72278</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72278"/>
		<updated>2013-02-09T16:25:45Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name. &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Scenario ===&lt;br /&gt;
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled &amp;quot;Impersonate a student as an Administrator.&amp;quot;&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature:5&amp;lt;/pre&amp;gt;&lt;br /&gt;
You can also specify several line numbers, allowing you to run several scenarios. &lt;br /&gt;
&amp;lt;pre&amp;gt;cucumber features/admin/impersonate_user.feature:5:14&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can specify the name of a scenario to run its instance.&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features --name &amp;quot;Impersonate a student as an Administrator&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run Tagged Features and/or Scenarios ===&lt;br /&gt;
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags Cucumber Wiki]&lt;br /&gt;
&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
== Cucumber Formatting ==&lt;br /&gt;
The output generated by cucumber can be formatted using decorators by modifying the std_opts variable in /config/cucumber.yml&lt;br /&gt;
These allow you to change the output from running tests in different ways. The default format is &amp;lt;pre&amp;gt;cucumber --format progress&amp;lt;/pre&amp;gt; but it is not very verbose. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
This format provides you with the most information and is the one to use when working the red-green-refactor cycle.&amp;lt;ref&amp;gt;http://rubyflare.com/2010/02/05/cucumber-formatters/&amp;lt;/ref&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;std_opts = &amp;quot;--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
Other options exist, &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72277</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72277"/>
		<updated>2013-02-09T16:24:19Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name. &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Scenario ===&lt;br /&gt;
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled &amp;quot;Impersonate a student as an Administrator.&amp;quot;&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature:5&amp;lt;/pre&amp;gt;&lt;br /&gt;
You can also specify several line numbers, allowing you to run several scenarios. &lt;br /&gt;
&amp;lt;pre&amp;gt;cucumber features/admin/impersonate_user.feature:5:14&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can specify the name of a scenario to run its instance.&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features --name &amp;quot;Impersonate a student as an Administrator&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run Tagged Features and/or Scenarios ===&lt;br /&gt;
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags Cucumber Wiki]&lt;br /&gt;
&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
== Cucumber Formatting ==&lt;br /&gt;
The output generated by cucumber can be formatted using decorators by modifying the std_opts variable in /config/cucumber.yml&lt;br /&gt;
These allow you to change the output from running tests in different ways. The default format is &amp;lt;pre&amp;gt;cucumber --format progress&amp;lt;/pre&amp;gt; but it is not very verbose. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
This format provides you with the most information and is the one to use when working the red-green-refactor cycle.&amp;lt;ref&amp;gt;http://rubyflare.com/2010/02/05/cucumber-formatters/&amp;lt;/ref&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;std_opts = &amp;quot;--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
Other options exist,&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72276</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72276"/>
		<updated>2013-02-09T16:17:12Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name. &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Scenario ===&lt;br /&gt;
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled &amp;quot;Impersonate a student as an Administrator.&amp;quot;&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature:5&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can specify the name of a scenario to run its instance.&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features --name &amp;quot;Impersonate a student as an Administrator&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run Tagged Features and/or Scenarios ===&lt;br /&gt;
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags Cucumber Wiki]&lt;br /&gt;
&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
== Cucumber Formatting ==&lt;br /&gt;
The output generated by cucumber can be formatted using decorators by modifying the std_opts variable in /config/cucumber.yml&lt;br /&gt;
These allow you to change the output from running tests in different ways. The default format is &amp;lt;pre&amp;gt;cucumber --format progress&amp;lt;/pre&amp;gt; but it is not very verbose. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
 &amp;lt;ref=http://rubyflare.com/2010/02/05/cucumber-formatters/&amp;gt;&lt;br /&gt;
This format provides you with the most information and is the one to use when working the red-green-refactor cycle.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;std_opts = &amp;quot;--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
Other options exist,&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72208</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72208"/>
		<updated>2013-02-09T00:01:47Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* seeds.rb */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name. &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Scenario ===&lt;br /&gt;
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled &amp;quot;Impersonate a student as an Administrator.&amp;quot;&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature:5&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can specify the name of a scenario to run its instance.&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features --name &amp;quot;Impersonate a student as an Administrator&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run Tagged Features and/or Scenarios ===&lt;br /&gt;
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags Cucumber Wiki]&lt;br /&gt;
&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
== Cucumber Decorators==&lt;br /&gt;
The output generated by cucumber can be formatted using decorators by modifying the std_opts variable in /config/cucumber.yml&lt;br /&gt;
&amp;lt;pre&amp;gt;std_opts = &amp;quot;--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} --strict --require features --tags ~@wip&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This enables clearer output of tests.&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72205</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72205"/>
		<updated>2013-02-08T23:55:22Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Running Tests */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name. &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Scenario ===&lt;br /&gt;
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled &amp;quot;Impersonate a student as an Administrator.&amp;quot;&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature:5&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can specify the name of a scenario to run its instance.&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features --name &amp;quot;Impersonate a student as an Administrator&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run Tagged Features and/or Scenarios ===&lt;br /&gt;
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags Cucumber Wiki]&lt;br /&gt;
&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
Cucumber decorators&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72204</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72204"/>
		<updated>2013-02-08T23:53:54Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Run a Single Feature */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name. &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Scenario ===&lt;br /&gt;
You can run specific scenario within a feature by specifying the line number. The following would run the scenario titled &amp;quot;Impersonate a student as an Administrator.&amp;quot;&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature:5&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can specify the name of a scenario to run its instance.&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features --name &amp;quot;Impersonate a student as an Administrator&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run Tagged Features and/or Scenarios ===&lt;br /&gt;
More information about running tests that share tags can be found in the [https://github.com/cucumber/cucumber/wiki/Tags Cucumber Wiki]&lt;br /&gt;
&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
Cucumber decorators&lt;br /&gt;
===Running Tests===&lt;br /&gt;
Run all features&lt;br /&gt;
Run a single feature&lt;br /&gt;
Run a single scenario&lt;br /&gt;
Undefined steps&lt;br /&gt;
Sample output and what it means&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72200</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72200"/>
		<updated>2013-02-08T23:41:04Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Feature: Impersonate User&lt;br /&gt;
     As an Administrator&lt;br /&gt;
     I should be able to impersonate users&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Before running cucumber, make sure all necessary gems are installed by running&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle install&amp;lt;/pre&amp;gt;&lt;br /&gt;
Create the database and tables&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:create&amp;lt;/pre&amp;gt;&lt;br /&gt;
Optionally prepare the test database&lt;br /&gt;
&amp;lt;pre&amp;gt;rake db:test:prepare&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run all Features ===&lt;br /&gt;
To run all cucumber features found within the /features directory&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber&amp;lt;/pre&amp;gt;&lt;br /&gt;
=== Run a Single Feature ===&lt;br /&gt;
To run all scenarios for a single cucumber feature one must specify the feature file name &lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
Alternatively, you can run a feature by specifying it's descriptor&lt;br /&gt;
&amp;lt;pre&amp;gt;bundle exec cucumber features/admin/impersonate_user.feature&amp;lt;/pre&amp;gt;&lt;br /&gt;
===Environment Configuration===&lt;br /&gt;
==== env.rb ====&lt;br /&gt;
Cucumber configuration variables can be edited in /features/support/env.rb&lt;br /&gt;
==== seeds.rb ====&lt;br /&gt;
The database can be prepopulated with data every time cucumber is run by editing the file /features/support/seeds.rb&lt;br /&gt;
&lt;br /&gt;
Cucumber decorators&lt;br /&gt;
===Running Tests===&lt;br /&gt;
Run all features&lt;br /&gt;
Run a single feature&lt;br /&gt;
Run a single scenario&lt;br /&gt;
Undefined steps&lt;br /&gt;
Sample output and what it means&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72164</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72164"/>
		<updated>2013-02-08T19:45:23Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Feature: Impersonate User&lt;br /&gt;
         As an Administrator&lt;br /&gt;
         I should be able to impersonate users&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student as an Administrator&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student that does not exist&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
===Setup===&lt;br /&gt;
Setting up seeds&lt;br /&gt;
Bundle install&lt;br /&gt;
Rake db:test:prepare&lt;br /&gt;
Cucumber decorators&lt;br /&gt;
===Running Tests===&lt;br /&gt;
Run all features&lt;br /&gt;
Run a single feature&lt;br /&gt;
Run a single scenario&lt;br /&gt;
Undefined steps&lt;br /&gt;
Sample output and what it means&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72163</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72163"/>
		<updated>2013-02-08T19:44:46Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Running Cucumber */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Feature: Impersonate User&lt;br /&gt;
         As an Administrator&lt;br /&gt;
         I should be able to impersonate users&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student as an Administrator&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student that does not exist&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;br /&gt;
Setting up seeds&lt;br /&gt;
Bundle install&lt;br /&gt;
Rake db:test:prepare&lt;br /&gt;
Cucumber decorators&lt;br /&gt;
Run all features&lt;br /&gt;
Run a single feature&lt;br /&gt;
Run a single scenario&lt;br /&gt;
Undefined steps&lt;br /&gt;
Sample output and what it means&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72162</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72162"/>
		<updated>2013-02-08T19:37:20Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Feature: Impersonate User&lt;br /&gt;
         As an Administrator&lt;br /&gt;
         I should be able to impersonate users&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student as an Administrator&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student that does not exist&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72161</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72161"/>
		<updated>2013-02-08T19:36:02Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Feature: Impersonate User&lt;br /&gt;
         As an Administrator&lt;br /&gt;
         I should be able to impersonate users&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student as an Administrator&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student that does not exist&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72160</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72160"/>
		<updated>2013-02-08T19:31:24Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Feature: Impersonate User&lt;br /&gt;
         As an Administrator&lt;br /&gt;
         I should be able to impersonate users&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student as an Administrator&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student that does not exist&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72159</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72159"/>
		<updated>2013-02-08T19:30:56Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Feature: Impersonate User&amp;lt;br&amp;gt;&lt;br /&gt;
         As an Administrator&amp;lt;br&amp;gt;&lt;br /&gt;
         I should be able to impersonate users&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student as an Administrator&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
     Scenario: Impersonate a student that does not exist&lt;br /&gt;
         Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
         When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
         And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
         And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
         When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
         Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72158</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72158"/>
		<updated>2013-02-08T19:29:40Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;Feature: Impersonate User&amp;lt;br&amp;gt;&lt;br /&gt;
     As an Administrator&amp;lt;br&amp;gt;&lt;br /&gt;
     I should be able to impersonate users&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72157</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72157"/>
		<updated>2013-02-08T19:29:14Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
Feature: Impersonate User&amp;lt;br&amp;gt;&lt;br /&gt;
     As an Administrator&amp;lt;br&amp;gt;&lt;br /&gt;
     I should be able to impersonate users&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student as an Administrator&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student that does not exist&lt;br /&gt;
     Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
     When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
     And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
     And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
     When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
     Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72156</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72156"/>
		<updated>2013-02-08T19:26:06Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;Feature: Impersonate User&amp;lt;br&amp;gt;&lt;br /&gt;
	As an Administrator&amp;lt;br&amp;gt;&lt;br /&gt;
	I should be able to impersonate users&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Scenario: Impersonate a student as an Administrator&lt;br /&gt;
&lt;br /&gt;
 	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student that does not exist&lt;br /&gt;
&lt;br /&gt;
	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72155</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72155"/>
		<updated>2013-02-08T19:25:52Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;Feature: Impersonate User&lt;br /&gt;
	As an Administrator&lt;br /&gt;
	I should be able to impersonate users&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Scenario: Impersonate a student as an Administrator&lt;br /&gt;
&lt;br /&gt;
 	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student that does not exist&lt;br /&gt;
&lt;br /&gt;
	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72154</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72154"/>
		<updated>2013-02-08T19:24:14Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
&amp;lt;p&amp;gt;Features provide a brief description about the functionality being tested.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Feature: Impersonate User&lt;br /&gt;
	As an Administrator&lt;br /&gt;
	I should be able to impersonate users&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
&amp;lt;p&amp;gt;Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Scenario: Impersonate a student as an Administrator&lt;br /&gt;
&lt;br /&gt;
 	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student that does not exist&lt;br /&gt;
&lt;br /&gt;
	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Gherkin provides multiple keywords to describe steps in a scenario such as:&amp;lt;/p&amp;gt;&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72151</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72151"/>
		<updated>2013-02-08T19:21:40Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Scenarios */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
Features provide a brief description about the functionality being tested.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
Feature: Impersonate User&lt;br /&gt;
	As an Administrator&lt;br /&gt;
	I should be able to impersonate users&lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student as an Administrator&lt;br /&gt;
&lt;br /&gt;
 	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student that does not exist&lt;br /&gt;
&lt;br /&gt;
	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
&lt;br /&gt;
	Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
Gherkin provides multiple keywords to describe steps in a scenario such as:&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72149</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72149"/>
		<updated>2013-02-08T19:20:11Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
Features provide a brief description about the functionality being tested.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
Feature: Impersonate User&lt;br /&gt;
	As an Administrator&lt;br /&gt;
	I should be able to impersonate users&lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student as an Administrator&lt;br /&gt;
 	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
	And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
	Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student that does not exist&lt;br /&gt;
	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
	Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
Gherkin provides multiple keywords to describe steps in a scenario such as:&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72148</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72148"/>
		<updated>2013-02-08T19:18:29Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Scenarios */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
Features provide a brief description about the functionality being tested.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&lt;br /&gt;
&lt;br /&gt;
'''Feature''': Impersonate User&lt;br /&gt;
	As an Administrator&lt;br /&gt;
	I should be able to impersonate users&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;em&amp;gt;Scenario: Impersonate a student as an Administrator&lt;br /&gt;
 	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
	And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
	Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
&amp;lt;/em&amp;gt;	&lt;br /&gt;
&amp;lt;em&amp;gt;&lt;br /&gt;
Scenario: Impersonate a student that does not exist&lt;br /&gt;
	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
	Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&amp;lt;/em&amp;gt;&lt;br /&gt;
Gherkin provides multiple keywords to describe steps in a scenario such as:&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72147</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72147"/>
		<updated>2013-02-08T19:17:24Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Features===&lt;br /&gt;
Features provide a brief description about the functionality being tested.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
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)&lt;br /&gt;
A feature is written in an explanatory syntax called Gherkin. For the Impersonate User feature, a feature would be described as.&lt;br /&gt;
&lt;br /&gt;
'''Feature''': Impersonate User&lt;br /&gt;
	As an Administrator&lt;br /&gt;
	I should be able to impersonate users&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
Each feature file can contain multiple scenarios. This is to test the same feature in different ways. 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.&lt;br /&gt;
&lt;br /&gt;
Scenario: Impersonate a student as an Administrator&lt;br /&gt;
 	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
	And a Student named &amp;quot;impersonated_account&amp;quot; created by &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
	Then I should be logged in as &amp;quot;impersonated_account&amp;quot;	&lt;br /&gt;
	&lt;br /&gt;
Scenario: Impersonate a student that does not exist&lt;br /&gt;
	Given an Administrator named &amp;quot;cucumber&amp;quot; exists&lt;br /&gt;
	When I log in as &amp;quot;cucumber&amp;quot;&lt;br /&gt;
	And I click the menu link &amp;quot;Impersonate User&amp;quot;&lt;br /&gt;
	And I fill in &amp;quot;user_name&amp;quot; with &amp;quot;impersonated_account&amp;quot;&lt;br /&gt;
	When I press &amp;quot;Impersonate&amp;quot;&lt;br /&gt;
	Then I should see &amp;quot;No user exists with the name 'impersonated_account'&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Gherkin provides multiple keywords to describe steps in a scenario such as:&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72146</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72146"/>
		<updated>2013-02-08T19:07:32Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
The syntax provides structure and meaning using special keywords including: &lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Cucumber Test File Directories==&lt;br /&gt;
===Features===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
Each .feature file tests a specific aspect of the system, such as an Administrator's ability to Impersonate a User.&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72145</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72145"/>
		<updated>2013-02-08T19:05:44Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Behavior Driven Development */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
The syntax provides structure and meaning using special keywords including: &lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Cucumber Test File Directories==&lt;br /&gt;
===Features===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72144</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72144"/>
		<updated>2013-02-08T19:05:07Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
The syntax provides structure and meaning using special keywords including: &lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
The BDD paradigm is that it's better to write code you wish you had and have a feature that is working instead of writing something you’re not sure is right and writing tests around it.&lt;br /&gt;
===Features===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuke-features.png|right]]&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72143</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72143"/>
		<updated>2013-02-08T19:01:42Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
The syntax provides structure and meaning using special keywords including: &lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
The BDD paradigm is that it's better to write code you wish you had and have a feature that is working instead of writing something you’re not sure is right and writing tests around it.&lt;br /&gt;
===Features===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[File:Cuke-features.png]]&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72142</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72142"/>
		<updated>2013-02-08T19:01:30Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
The syntax provides structure and meaning using special keywords including: &lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
The BDD paradigm is that it's better to write code you wish you had and have a feature that is working instead of writing something you’re not sure is right and writing tests around it.&lt;br /&gt;
===Features===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[center][[File:Cuke-features.png]][/center]&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72141</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72141"/>
		<updated>2013-02-08T19:01:10Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
The syntax provides structure and meaning using special keywords including: &lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
The BDD paradigm is that it's better to write code you wish you had and have a feature that is working instead of writing something you’re not sure is right and writing tests around it.&lt;br /&gt;
===Features===&lt;br /&gt;
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.&lt;br /&gt;
[[File:Cuke-features.png]]&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Cuke-features.png&amp;diff=72140</id>
		<title>File:Cuke-features.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Cuke-features.png&amp;diff=72140"/>
		<updated>2013-02-08T19:00:46Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: Cucumber file directory for features&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Cucumber file directory for features&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72139</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72139"/>
		<updated>2013-02-08T18:58:59Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Features */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
The syntax provides structure and meaning using special keywords including: &lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
The BDD paradigm is that it's better to write code you wish you had and have a feature that is working instead of writing something you’re not sure is right and writing tests around it.&lt;br /&gt;
===Features===&lt;br /&gt;
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.&lt;br /&gt;
[[File:http://i.imgur.com/yxv2YVi.png]]&lt;br /&gt;
&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72054</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72054"/>
		<updated>2013-02-08T00:21:44Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Gherkin */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
The syntax provides structure and meaning using special keywords including: &lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
The BDD paradigm is that it's better to write code you wish you had and have a feature that is working instead of writing something you’re not sure is right and writing tests around it.&lt;br /&gt;
===Features===&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72053</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72053"/>
		<updated>2013-02-08T00:20:29Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Gherkin */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
&lt;br /&gt;
A Gherkin file is given its structure and meaning using a set of special keywords. &lt;br /&gt;
These include:&lt;br /&gt;
* Feature &lt;br /&gt;
* Background &lt;br /&gt;
* Scenario&lt;br /&gt;
* Given&lt;br /&gt;
* When&lt;br /&gt;
* Then&lt;br /&gt;
* And&lt;br /&gt;
* But&lt;br /&gt;
* Scenario Outline&lt;br /&gt;
* Examples&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
The BDD paradigm is that it's better to write code you wish you had and have a feature that is working instead of writing something you’re not sure is right and writing tests around it.&lt;br /&gt;
===Features===&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72052</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72052"/>
		<updated>2013-02-08T00:16:58Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Gherkin */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
Gherkin is the language used to write Cucumber executable feature specifications in conversational  syntax.&lt;br /&gt;
&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
The BDD paradigm is that it's better to write code you wish you had and have a feature that is working instead of writing something you’re not sure is right and writing tests around it.&lt;br /&gt;
===Features===&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72051</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72051"/>
		<updated>2013-02-08T00:13:28Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Behavior Driven Development */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
The BDD paradigm is that it's better to write code you wish you had and have a feature that is working instead of writing something you’re not sure is right and writing tests around it.&lt;br /&gt;
===Features===&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72044</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72044"/>
		<updated>2013-02-07T06:35:03Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Cucumber Stack==&lt;br /&gt;
===Gherkin===&lt;br /&gt;
===Capybara===&lt;br /&gt;
&lt;br /&gt;
==Behavior Driven Development==&lt;br /&gt;
===Features===&lt;br /&gt;
===Scenarios===&lt;br /&gt;
===Step Definitions===&lt;br /&gt;
&lt;br /&gt;
==Running Cucumber==&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72043</id>
		<title>Using Cucumber with Expertiza</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Using_Cucumber_with_Expertiza&amp;diff=72043"/>
		<updated>2013-02-07T06:33:37Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: Basic Outline&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Cucumber Stack&lt;br /&gt;
=Gherkin&lt;br /&gt;
=Capybara&lt;br /&gt;
&lt;br /&gt;
Behavior Driven Development&lt;br /&gt;
=Features&lt;br /&gt;
=Scenarios&lt;br /&gt;
=Step Definitions&lt;br /&gt;
&lt;br /&gt;
Running Cucumber&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2012/ch2a_2w5_dp&amp;diff=68319</id>
		<title>CSC/ECE 517 Fall 2012/ch2a 2w5 dp</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2012/ch2a_2w5_dp&amp;diff=68319"/>
		<updated>2012-10-26T22:10:12Z</updated>

		<summary type="html">&lt;p&gt;Pmocampo: /* Popular Agile Methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Agile Software Development ==&lt;br /&gt;
=== Introduction ===&lt;br /&gt;
==== Why Agile? ====&lt;br /&gt;
James Shore and Shane Warden &amp;lt;ref&amp;gt;Shore, James and Warden, Shane. ''The Art of Agile Development''. O’Reilly Media, Inc., 2008, p. 4.&amp;lt;/ref&amp;gt; state that the benefit for developers to follow a Agile software development process is to deliver successful products to the client or customer.&lt;br /&gt;
He defines success into 3 types:&lt;br /&gt;
# Organizational&lt;br /&gt;
#* Deliver value and decrease costs to increase return on investment.&lt;br /&gt;
# Technical&lt;br /&gt;
#* Elegant and maintainable code is produced.&lt;br /&gt;
# Personal&lt;br /&gt;
#* Developers find the project fun and rewarding which lead them to be intrinsically motivated and devote passion to the work.&lt;br /&gt;
&lt;br /&gt;
==== The Agile Manifesto ====&lt;br /&gt;
The Agile Manifesto is a set of [http://agilemanifesto.org/principles.html 12 principles] that provide a foundation for agile methodologies.&lt;br /&gt;
&lt;br /&gt;
The core principles of the manifesto are as follows &amp;lt;ref name=&amp;quot;Agile Manifesto&amp;quot;&amp;gt;Manifesto for Agile Software Development http://agilemanifesto.org/ &amp;lt;/ref&amp;gt; : &lt;br /&gt;
&lt;br /&gt;
* Individuals and interactions over processes and tools&lt;br /&gt;
* Working software over comprehensive documentation &lt;br /&gt;
* Customer collaboration over contract negotiation&lt;br /&gt;
* Responding to change over following a plan&lt;br /&gt;
&lt;br /&gt;
=== Values ===&lt;br /&gt;
There are four concepts that represent the main values of Agile software development.&lt;br /&gt;
#Adaptability&lt;br /&gt;
#Transparency&lt;br /&gt;
#Simplicity&lt;br /&gt;
#Unity&lt;br /&gt;
&lt;br /&gt;
[[File:Agile_poster.png]]&lt;br /&gt;
==== Adaptability ====&lt;br /&gt;
Adaptability is purported to be the most important value &amp;lt;ref&amp;gt;The Agile Leader: Adaptability&lt;br /&gt;
 http://blogs.forrester.com/tom_grant/11-04-19-adaptability_may_turn_out_to_be_agiles_most_important_virtue&amp;lt;/ref&amp;gt; of Agile methodologies.&lt;br /&gt;
&lt;br /&gt;
This value forces teams to plan for inevitable change in a mindful manner.&lt;br /&gt;
&lt;br /&gt;
The focus for Adaptability can be summarized by these two principles stated in the Agile manifesto.&lt;br /&gt;
*''&amp;quot;Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.&amp;quot;''&lt;br /&gt;
*''&amp;quot;At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.&amp;quot;''&lt;br /&gt;
&lt;br /&gt;
There are three components in Adaptability &amp;lt;ref&amp;gt;Adaptation in project management through agile http://searchsoftwarequality.techtarget.com/feature/Adaptation-in-project-management-through-agile&amp;lt;/ref&amp;gt; These three components must ALL be open to change in order to have a fully adaptable agile environment.&lt;br /&gt;
#Product - quality code and adequate testing will ensure product functionality after changes have been made.&lt;br /&gt;
#Process - practices that allow the team to adapt must be in place.&lt;br /&gt;
#People - developers, management, and stakeholders must have the proper attitude that is accepting of change and want to work in a collaborative way. If people don't collaborate, the full advantages of an adaptive process are lost.&lt;br /&gt;
==== Transparency ====&lt;br /&gt;
Transparency in an Agile environment extends from simple communication between individuals working on the project to the project's definition and mission statement itself.&amp;lt;ref&amp;gt;The Concept of Transparency in Agile Project Management http://p-a-m.org/2012/03/the-concept-of-transparency-in-agile-project-management/&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The high value on ''Transparency'' can be summarized by these two principles stated in the Agile manifesto.&lt;br /&gt;
* ''Individuals and interactions over processes and tools''&lt;br /&gt;
* ''Customer collaboration over contract negotiation''&lt;br /&gt;
&lt;br /&gt;
Transparency in Agile project management is intended to create an open environment where communication and accountability are highly prized.&lt;br /&gt;
Agile does not limit embracing this value simply to interaction between developers and project managers.  As the second bullet point alludes to, this value extends to customer interaction as well.&lt;br /&gt;
The idea is to generate a unifying project goal that the developers, project managers and, customer can all identify with.&lt;br /&gt;
&lt;br /&gt;
==== Simplicity ====&lt;br /&gt;
The Agile Manifesto refers to simplicity as, the art of maximizing the amount of work not done is essential. &amp;lt;ref name=&amp;quot;Agile Manifesto&amp;quot;/&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Simplicity is generally referred to as a little bit less than just enough process.  &lt;br /&gt;
The Agile methodologies attempt to keep the project focused on progressing to the project while eliminating process that can unintentionally slow development.&lt;br /&gt;
This all plays into the Agile Manifesto's statement of &amp;quot;Working software over comprehensive documentation&amp;quot;&lt;br /&gt;
&lt;br /&gt;
There are three aspects or faces to simplicity &amp;lt;ref&amp;gt;Agile Software Development and the Three Faces of Simplicity http://www.informit.com/articles/article.aspx?p=25944&amp;lt;/ref&amp;gt;&lt;br /&gt;
* Do less - This facet refers to doing fewer activities, producing fewer documents and, reducing management reports.&lt;br /&gt;
* Do better - A simple, straight forward model for the project helps the team be sure their design is correct.&lt;br /&gt;
* Do swarms - An appropriate set of simple rules helps a highly motivated group of interactive individuals encourages higher level functions like innovation and creativity.&lt;br /&gt;
&lt;br /&gt;
==== Unity ====&lt;br /&gt;
Unity is a pervading ideal through most everything the Agile method is intended to accomplish.  The value placed on unity is reflected in how Agile strives to create a team of customers, developers and project managers that have a single goal of completing a specific project.  In addition it is focused on bringing the product team's understanding, goals and, communication in line with the customer's expectations and goals for the project itself.  By working together while sharing experiences, knowledge and ideas Agile strives to provide a product that accomplishes the goal that the project was intended to accomplish.&lt;br /&gt;
&lt;br /&gt;
=== Best Practices ===&lt;br /&gt;
These are some of today's most common Agile practices &amp;lt;ref&amp;gt;Professional Management: Top ten agile best practices http://profmgmt.wordpress.com/2007/01/11/top-ten-agile-best-practices/&amp;lt;/ref&amp;gt;. Before adopting a practice, teams must be able understand their priorities and problems affecting the product before you can decide which practices will be the solutions to those problems &amp;lt;ref&amp;gt;Professional Management: Which best practice to implement first? http://profmgmt.wordpress.com/2007/01/11/which-best-practice-to-implement-first/&amp;lt;/ref&amp;gt;. &lt;br /&gt;
*Common coding guidelines&lt;br /&gt;
*Refactoring&lt;br /&gt;
*Regression testing&lt;br /&gt;
*Continuous integration&lt;br /&gt;
*Test driven development&lt;br /&gt;
*Active stakeholder participation&lt;br /&gt;
*Pair programming&lt;br /&gt;
&lt;br /&gt;
=== Popular Agile Methods ===&lt;br /&gt;
Martin Fowler refers to Agile Software Development as a philosophy from which several different types of methodologies inherit their characteristics. Thus, it should be considered as an umbrella for the agile methods organizations choose to implement in their software projects &amp;lt;ref name=&amp;quot;Agile Flavors&amp;quot;&amp;gt;Flavors of Agile Development http://martinfowler.com/articles/newMethodology.html#FlavorsOfAgileDevelopment&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The following are some of the most common Agile Methods practiced by industry organizations.&lt;br /&gt;
==== Extreme Programming (XP) ====&lt;br /&gt;
Extreme Programming (XP) is one of the most practiced and well-known Agile methods and it is characterized by four core values &amp;lt;ref&amp;gt;A Practical Guide to Seven Agile Methodologies, Part 1 http://www.devx.com/architect/Article/32761/0&amp;lt;/ref&amp;gt;: &lt;br /&gt;
*Communication &lt;br /&gt;
*Simplicity &lt;br /&gt;
*Feedback &lt;br /&gt;
*Courage&lt;br /&gt;
&lt;br /&gt;
XP's emphasis is on technical practices to ensure frequent delivery of functional software through skillful development.&lt;br /&gt;
The practice of constant code reviews plays a big part in XP to ensure that development is skillful and code is fully functioning. This requires a high level of teamwork from team members and, therefore, a large fous on pair programming and refactoring must be in place. All three components allow teams to develop designs that increase business value in a simple and effective manner. &lt;br /&gt;
XP is characterized by short iterations that last anywhere between one and four weeks.&lt;br /&gt;
&lt;br /&gt;
==== Scrum ====&lt;br /&gt;
Scrum is an agile method for product development that focuses on individuals and teams. &lt;br /&gt;
&lt;br /&gt;
Project development generally occurs in small iterative pieces.  The intention is to encourage creativity while providing built in design time for feedback analysis.  Scrum provides a simple framework to guide developers and managers during product development.  The goal of the simple framework is to provide just enough structure for empirical process control based off of feedback loops.&amp;lt;ref&amp;gt;Scrum - Wikipedia http://en.wikipedia.org/wiki/Scrum_(development)&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The fundamental process is defined by the three following roles&amp;lt;ref&amp;gt;Scrum.org http://www.scrum.org/Resources/What-is-Scrum&amp;lt;/ref&amp;gt;&lt;br /&gt;
* Product Owners responsible for deciding on what will be built in the upcoming time frame&lt;br /&gt;
* Development Teams - responsible for building the product defined by the Product Owners in the allotted time frame.  This is followed by a demonstration to the Product Owners.&lt;br /&gt;
* Scrum Masters - responsible for smoothing out and improving the process.&lt;br /&gt;
&lt;br /&gt;
==== Crystal ====&lt;br /&gt;
Crystal is a a variety of sets of methods developed by Alistair Cockburn in the '90s. Each variation's primary focus on improving performance is done through communication between people and their talents over the process in which a team follows &amp;lt;ref name=&amp;quot;Agile Paper&amp;quot;&amp;gt;An Introduction to Agile Methods http://www.cs.umd.edu/~mvz/cmsc435-s09/pdf/agile-paper.pdf&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The Crystal methods prioritize safety in a project's outcome, efficiency, and habitability. These priorities motivate a focus on frequent delivery, reflective improvement, and close communication &amp;lt;ref name=&amp;quot;Agile Flavors&amp;quot;/&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The name Crystal represents the different facets (like that of a gemstone) or methods available that focus around a central core. The belief that different approaches are required as the criticality &amp;lt;ref name=&amp;quot;Agile Flavors&amp;quot;/&amp;gt; and the following of a project vary &amp;lt;ref name=&amp;quot;Agile Paper&amp;quot;/&amp;gt;:&lt;br /&gt;
*Team Size: teams can be of any size but in choosing members, focus on talented people &lt;br /&gt;
*Iteration Length: iterations can be up to 4 months in length  for highly critical projects &lt;br /&gt;
*Distributed Teams: teams can be distributed across different locations&lt;br /&gt;
&lt;br /&gt;
Criticality can be classified as defects causing the loss or affecting the state of &amp;lt;ref name=&amp;quot;Agile Paper&amp;quot;/&amp;gt;:&lt;br /&gt;
#Comfort&lt;br /&gt;
#Discretionary money&lt;br /&gt;
#Essential money&lt;br /&gt;
#Life&lt;br /&gt;
&lt;br /&gt;
Each version is assigned a color and it represents intensity of the degree of communication required among size of the team to get the job done. The different colors include Crystal Clear, Yellow, Orange and Red &amp;lt;ref name=&amp;quot;Agile Paper&amp;quot;/&amp;gt;. The Crystal methods present an outline of what teams should focus on instead of a comprehensive guide &amp;lt;ref name=&amp;quot;Agile Flavors&amp;quot;/&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
As teams grow, the method hardens and more restraints must be put in place. Some agility may be lost, but because of a team's common mindset and understanding, the method remains Agile &amp;lt;ref name=&amp;quot;Agile Paper&amp;quot;/&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Lean Development ====&lt;br /&gt;
&lt;br /&gt;
Lean Development is a top-down approach based on lean processes (also referred to as the Toyota Production System &amp;lt;ref name=&amp;quot;Agile Flavors&amp;quot;/&amp;gt;) used in the automotive industry of the 1980s. It was started by Bob Charette and its focus is to provide a set management ideas and reasonings while the development process (team size, iteration length, team distribution, and criticality) is left untouched. The management guidelines Lean Development provides are &amp;lt;ref name=&amp;quot;Agile Paper&amp;quot;/&amp;gt;:&lt;br /&gt;
&lt;br /&gt;
#Customer Satisfaction is the top priority  &lt;br /&gt;
#Provide the biggest value for the money&lt;br /&gt;
#Active customer participation will lead to success&lt;br /&gt;
#Projects are a team effort&lt;br /&gt;
#Everything is changeable&lt;br /&gt;
#Domain, not point, solutions&lt;br /&gt;
#Don't just construct, complete a project&lt;br /&gt;
#80% solution today is better than a 100% solution tomorrow&lt;br /&gt;
#Be minimalist&lt;br /&gt;
#Needs determine technology&lt;br /&gt;
#Product growth is feature growth, not size growth.&lt;br /&gt;
#Never try to go beyond the limits of Lean Development&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Pmocampo</name></author>
	</entry>
</feed>