Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w46 ga

2012-11-19T21:44:46Z

Ggsingh:

=Builder Pattern and a directory of sites=
Internet has grown to be the new generation prime source of information. The objective of this page is to compile a directory of websites that discuss one of the Object Oriented Design pattern called the Builder Pattern. The aim of this wiki-page is to compile the best resources available online for studying the [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern].
This page will take the reader systematically through the best articles that can be referenced at every point of study of the topic in discussion. There is also a list of interesting video tutorials and discussions on online forums regarding the Builder Design Pattern

==Scenarios==
The best way to learn about a [http://en.wikipedia.org/wiki/Design_pattern Design Pattern] is to begin with the scenarios that it can be implemented in. It is important to understand what real life situations and design issues necessitate the use of a pattern. It gives our study a more practical approach than simply beginning with the definitions of the patterns. This approach of studying begins with an exemplary motivation to study the pattern in the first place. There are a lot of interesting scenarios that highlight the need for the Builder Pattern, some of which are present in the following links.

'''Animal model making example:-'''
http://www.codeproject.com/Articles/42415/Builder-Design-Pattern

*This article in codeproject.com explains one simple scenario where a builder pattern is implemented. A day care teacher needs to maintain a set of moulds for creating clay animals. Each set consists of tools like head, body, tail, arm and leg of a particular animal. Each of these tools are used to create individual parts of the animal that are then compiled together to form a complete figure.

'''Instrument manufacturing example:-'''
http://mahemoff.com/paper/software/gofMetaphors/builder.shtml

*Here, we see how the Builder Pattern could be used to implement a generic Instrument manufacturing system that can be used to not only specialise the kind of instrument being built but also the kind of users interacting with the system.

Each of the other resources cited on this page also contain different scenarios in which the Builder Pattern can be implemented.

==Definition==
The definition by the Gang of Four states that the Builder Pattern separates the construction of a complex object from its representation so that the same construction process can create different representations.
It is a type of creational pattern that focuses on constructing complex objects step by step. This pattern is very similar to the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory design pattern].

Typically, languages like Java provide constructors to create objects. But there are multiple problems that start creeping in if there are many different objects that take many different parameters that can be classified as either optional or mandatory.

The detailed explanations can be found at the following links:-

http://www.javacodegeeks.com/2012/07/builder-design-pattern-in-java.html

*One interesting blog that aptly explains the builder pattern and the problems that it solves.

http://www.oodesign.com/builder-pattern.html

*This link also provides good literature on motivations for using the builder design pattern.

==Design Pattern Structure==
In this pattern, a process is used to create complex objects by only specifying its type and contents. The details related to the object’s representation like the actual steps involved in creating the complex object are encapsulated. In this way, the same process can be used to create different object forms.

[[File:Builder UML class diagram.svg.png]]

The pattern consists of four main parts :-
* Builder,
* Concrete Builder,
* Director and
* Product.

A Builder is an interface that holds actions involved in creating the complex object. The complex object that is being created here is represented by the Product.

The Concrete Builder create and assemble the parts that constitute the Product object. They implement the Builder interface.

The Director object is responsible for constructing the Product by delegating the actual creation and assembly to the appropriate Concrete Builder.

The design pattern structure is explained quite well in the link:-

http://www.avajava.com/tutorials/lessons/builder-pattern.html?page=1

Further reading

http://java.dzone.com/news/design-pattern-builder-pattern

This link gives a good explanation of how the four modules co-ordinate together to solve the object creation problem in a clean and Object-Oriented manner.

==Implementation Examples==
The semantics and methods of implementing the Builder Pattern differ with the language chosen. The following links contain detailed implementation of the Builder Pattern in different scenarios

'''Java'''

http://sourcemaking.com/design_patterns/builder/java/2

The scenario of a customer ordering a pizza at a restaurant

'''C#'''

http://sourcemaking.com/design_patterns/builder/c%2523

The generic scenario

'''C++'''

http://sourcemaking.com/design_patterns/builder/cpp/1

The scenario is of distributing work over different operating systems.

'''PHP'''

http://sourcemaking.com/design_patterns/builder/php/1

This link gives the implementation of Builder pattern in PhP. The example taken here is of creating an HTML page wherein the Director gives the Builder parameters like the page title, page heading, page data among the others to construct an HTML page as the Product.

==Difference between Builder Pattern and Factory Pattern==
The most common confusion in Design Patterns is the distinction between Builder and the Factory Pattern. A very explanatory discussion on the difference between the two patterns that is worth following is at

http://stackoverflow.com/questions/757743/what-is-the-difference-between-builder-design-pattern-and-factory-design-pattern

Both these patterns are designed to achieve the same objective of building complex structured objects. The difference is in the approach though. Factory pattern describes an object that knows how to create several different but related kinds of object in one step, where the specific type is chosen based on given parameters.Builder pattern describes an object that knows how to craft another object of a specific type over several steps.
Thus unlike factory pattern, builder pattern has a sequential step-by-step approach wherein each step has a small logic that adds value to the construction and the object will be returned as the result of the last step.
A small but enough explanatory article on Factory Pattern can be found at

http://javapapers.com/design-patterns/abstract-factory-pattern/

following which the next article can clearly explain the difference between the two patterns

http://javapapers.com/design-patterns/builder-pattern/

==Related concepts and terms==
*Builder focuses on constructing a complex object step by step. [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
*Builder often builds a Composite.
*Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
*Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components are built. Abstract Factory, Builder, and Prototype can useSingleton in their implementations.
*Builders are good candidates for a fluent interface.

==Video Tutorials==

The video tutorials listed here carry explanations along with code implementations:-

http://www.youtube.com/watch?v=jstef_eUM6E

*This 9 minute video tutorial by questpond.com is a conceptual explanation of the Builder Pattern with the help of 2 real life examples of tea preparation and one of generating reports. The video also illustrates a detailed Java implementation of the report generation system.

http://www.youtube.com/watch?v=9XnsOpjclUg

*This 13 minute video tutorial by newthinktank.com illustrates a full fledged implementation of a Robot building system using the Builder Pattern.

http://www.youtube.com/watch?v=1xo_sVKcHbY

*This 9 minute video tutorial by zaneacademy gives a thorough explaantion of the key idea behind the Builder Pattern and its basic characteristics. It then goes on to explain the UML diagram of the Builder Pattern with an example.

http://www.youtube.com/watch?v=L-iKVzW56mY&playnext=1&list=PL39AB9FE0F96FADA5&feature=results_video

*This 9 minute video tutorial by questpond.com about the implementation of the Builder Pattern in Java. We see an in-depth analysis of a car building system and how the builder pattern is used in its implementation. The video contains a complete code run of the example and the various methods used.

http://www.youtube.com/watch?v=S9p_mwz1dd4

*The study of design patterns is complete only when one can differentiate between the various patterns This 12 minute video

==Online Discussions==
These are some interesting online discussions on various issues related to the Builder Pattern

http://stackoverflow.com/questions/5211039/real-world-examples-of-the-builder-pattern

*In this discussion on stackoverflow, the members are citing some personal coding experiences where the used the Builder Pattern and how.

http://stackoverflow.com/questions/328496/when-would-you-use-the-builder-pattern?lq=1

*In this discussion on stackoverflow, the members are discussing various situations where the Builder Pattern scores over the Factory pattern, the Telescoping Constructor pattern and the JavaBean pattern. The differences between the patterns become clearer through this discussion. What is even more useful is that one of the participants of the discussion has also posted an implementation to highlight the difference.

http://stackoverflow.com/questions/4737836/can-the-builder-pattern-ever-be-doing-too-much?rq=1

*This is an interesting discussion where members discuss how the builder pattern trades off against the factory pattern not just conceptually but in actual practice. This discussion gives hints at choosing the best design pattern for a situation and what questions one must ask oneself before finalising the design pattern.

http://stackoverflow.com/questions/5674513/differences-between-builder-pattern-vs-template-method?rq=1

*This discussion on stackoverflow.com is about the difference between the builder pattern and the template pattern. It also highlights the crucial distinctions between other patterns as well.

http://stackoverflow.com/questions/10941464/builder-pattern-with-inheritance?rq=1

*This is an interesting discussion of using the Builder Pattern in an inheritance hierarchy.

http://stackoverflow.com/questions/7302891/the-builder-pattern-and-a-large-number-of-mandatory-parameters?rq=1

*This discussion on stackoverflow focusses on the general good practices that can be used while implementing the Builder pattern. Which secondary design decisions are helpful and which could raise problems during implementation. The members are each giving their own implementation practices and how they trade off when compared to other conventions followed while implementing the Builder pattern.

CSC/ECE 517 Fall 2012/ch2b 2w46 ga

2012-11-18T20:32:07Z

Ggsingh:

Wiki Formatted
=Builder Pattern and a directory of sites=
Internet has grown to be the new generation prime source of information. The objective of this page is to compile a directory of websites that discuss one of the Object Oriented Design pattern called the Builder Pattern. The aim of this wiki-page is to compile the best resources available online for studying the [http://en.wikipedia.org/wiki/Builder_pattern Builder Pattern].

==Scenarios==
The best way to learn about a [http://en.wikipedia.org/wiki/Design_pattern Design Pattern] is to begin with the scenarios that it can be implemented in. It is important to understand what real life situations and design issues necessitate the use of a pattern. It gives our study a more practical approach than simply beginning with the definitions of the patterns. This approach of studying begins with an exemplary motivation to study the pattern in the first place. There are a lot of interesting scenarios that highlight the need for the Builder Pattern, some of which are present in the following links.

'''Animal model making example:-'''
http://www.codeproject.com/Articles/42415/Builder-Design-Pattern

*This article in codeproject.com explains one simple scenario where a builder pattern is implemented. A day care teacher needs to maintain a set of moulds for creating clay animals. Each set consists of tools like head, body, tail, arm and leg of a particular animal. Each of these tools are used to create individual parts of the animal that are then compiled together to form a complete figure.

'''Instrument manufacturing example:-'''
http://mahemoff.com/paper/software/gofMetaphors/builder.shtml

*Here, we see how the Builder Pattern could be used to implement a generic Instrument manufacturing system that can be used to not only specialise the kind of instrument being built but also the kind of users interacting with the system.

Each of the other resources cited on this page also contain different scenarios in which the Builder Pattern can be implemented.

==Definition==
The definition by the Gang of Four states that the Builder Pattern separates the construction of a complex object from its representation so that the same construction process can create different representations.
It is a type of creational pattern that focuses on constructing complex objects step by step. This pattern is very similar to the [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory design pattern].

Typically, languages like Java provide constructors to create objects. But there are multiple problems that start creeping in if there are many different objects that take many different parameters that can be classified as either optional or mandatory.

The detailed explanations can be found at the following links:-

http://www.javacodegeeks.com/2012/07/builder-design-pattern-in-java.html

*One interesting blog that aptly explains the builder pattern and the problems that it solves.

http://www.oodesign.com/builder-pattern.html

*This link also provides good literature on motivations for using the builder design pattern.

==Design Pattern Structure==
In this pattern, a process is used to create complex objects by only specifying its type and contents. The details related to the object’s representation like the actual steps involved in creating the complex object are encapsulated. In this way, the same process can be used to create different object forms.

[[File:Builder UML class diagram.svg.png]]

The pattern consists of four main parts :-
* Builder,
* Concrete Builder,
* Director and
* Product.

A Builder is an interface that holds actions involved in creating the complex object. The complex object that is being created here is represented by the Product.

The Concrete Builder create and assemble the parts that constitute the Product object. They implement the Builder interface.

The Director object is responsible for constructing the Product by delegating the actual creation and assembly to the appropriate Concrete Builder.

The design pattern structure is explained quite well in the link:-

http://www.avajava.com/tutorials/lessons/builder-pattern.html?page=1

Further reading

http://java.dzone.com/news/design-pattern-builder-pattern

This link gives a good explanation of how the four modules co-ordinate together to solve the object creation problem in a clean and Object-Oriented manner.

==Implementation Examples==
The semantics and methods of implementing the Builder Pattern differ with the language chosen. The following links contain detailed implementation of the Builder Pattern in different scenarios

'''Java'''

http://sourcemaking.com/design_patterns/builder/java/2

The scenario of a customer ordering a pizza at a restaurant

'''C#'''

http://sourcemaking.com/design_patterns/builder/c%2523

The generic scenario

'''C++'''

http://sourcemaking.com/design_patterns/builder/cpp/1

The scenario is of distributing work over different operating systems.

'''PHP'''

http://sourcemaking.com/design_patterns/builder/php/1

This link gives the implementation of Builder pattern in PhP. The example taken here is of creating an HTML page wherein the Director gives the Builder parameters like the page title, page heading, page data among the others to construct an HTML page as the Product.

==Related concepts and terms==
*Builder focuses on constructing a complex object step by step. [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
*Builder often builds a Composite.
*Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
*Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components are built. Abstract Factory, Builder, and Prototype can useSingleton in their implementations.
*Builders are good candidates for a fluent interface.

==Difference between Builder Pattern and Factory Pattern==
The most common confusion in Design Patterns is the distinction between Builder and Factory Pattern. The most crucial points of difference can be found at the following sites:

==Video Tutorials==

The video tutorials listed here carry explanations along with code implementations:-

http://www.youtube.com/watch?v=jstef_eUM6E

*This 9 minute video tutorial by questpond.com is a conceptual explanation of the Builder Pattern with the help of 2 real life examples of tea preparation and one of generating reports. The video also illustrates a detailed Java implementation of the report generation system.

http://www.youtube.com/watch?v=9XnsOpjclUg

*This 13 minute video tutorial by newthinktank.com illustrates a full fledged implementation of a Robot building system using the Builder Pattern.

http://www.youtube.com/watch?v=1xo_sVKcHbY

*This 9 minute video tutorial by zaneacademy gives a thorough explaantion of the key idea behind the Builder Pattern and its basic characteristics. It then goes on to explain the UML diagram of the Builder Pattern with an example.

http://www.youtube.com/watch?v=L-iKVzW56mY&playnext=1&list=PL39AB9FE0F96FADA5&feature=results_video

*This 9 minute video tutorial by questpond.com about the implementation of the Builder Pattern in Java. We see an in-depth analysis of a car building system and how the builder pattern is used in its implementation. The video contains a complete code run of the example and the various methods used.

http://www.youtube.com/watch?v=S9p_mwz1dd4

*The study of design patterns is complete only when one can differentiate between the various patterns This 12 minute video

==Online Discussions==
These are some interesting online discussions on various issues related to the Builder Pattern

http://stackoverflow.com/questions/5211039/real-world-examples-of-the-builder-pattern

*In this discussion on stackoverflow, the members are citing some personal coding experiences where the used the Builder Pattern and how.

http://stackoverflow.com/questions/328496/when-would-you-use-the-builder-pattern?lq=1

*In this discussion on stackoverflow, the members are discussing various situations where the Builder Pattern scores over the Factory pattern, the Telescoping Constructor pattern and the JavaBean pattern. The differences between the patterns become clearer through this discussion. What is even more useful is that one of the participants of the discussion has also posted an implementation to highlight the difference.

http://stackoverflow.com/questions/4737836/can-the-builder-pattern-ever-be-doing-too-much?rq=1

*This is an interesting discussion where members discuss how the builder pattern trades off against the factory pattern not just conceptually but in actual practice. This discussion gives hints at choosing the best design pattern for a situation and what questions one must ask oneself before finalising the design pattern.

http://stackoverflow.com/questions/5674513/differences-between-builder-pattern-vs-template-method?rq=1

*This discussion on stackoverflow.com is about the difference between the builder pattern and the template pattern. It also highlights the crucial distinctions between other patterns as well.

http://stackoverflow.com/questions/10941464/builder-pattern-with-inheritance?rq=1

*This is an interesting discussion of using the Builder Pattern in an inheritance hierarchy.

http://stackoverflow.com/questions/7302891/the-builder-pattern-and-a-large-number-of-mandatory-parameters?rq=1

*This discussion on stackoverflow focusses on the general good practices that can be used while implementing the Builder pattern. Which secondary design decisions are helpful and which could raise problems during implementation. The members are each giving their own implementation practices and how they trade off when compared to other conventions followed while implementing the Builder pattern.

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T01:20:34Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction'''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides [http://www.debian.org/doc/manuals/intro-i18n/ i18n] language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium].

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave] required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''On Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

===='''Given/When/Then + And/But construct'''====

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre-conditions of [http://en.wikipedia.org/wiki/Use_case Usecase].

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple English is what makes it unique letting clients who are not aware of the technicalities of a system, voice their opinion in the development process and hence the development is always in sync with the requirement.

=='''Ongoing developments'''==
Cucumber has rapidly become one of the most preferred tools for automated testing. Aslak Hellesoy and his team are working on further advancements and improvements to the tool. Improving the documentation via the [http://pragprog.com/book/hwcuc/the-cucumber-book "The Cucumber Book"] being one of them. The book continues to be revised to keep up with its rapid evolution. Currently, Cucumber tests run on JVMs through JRuby. But to overcome the inherent latency, the team is working on a native Java implementation of the tool which can be built in to the Java development environment. During this adaptation to Java, the team also found aspects of the Ruby implementation that could be improved to make it much more flexible.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Further reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T01:15:19Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction'''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides [http://www.debian.org/doc/manuals/intro-i18n/ i18n] language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium].

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave] required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''On Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

===='''Given/When/Then + And/But construct'''====

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre-conditions of [http://en.wikipedia.org/wiki/Use_case Usecase].

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple English is what makes it unique letting clients who are not aware of the technicalities of a system, voice their opinion in the development process and hence the development is always in sync with the requirement.

=='''Ongoing developments'''==
Cucumber has rapidly become one of the most preferred tools for automated testing. Aslak Hellesoy and his team are working on further advancements and improvements to the tool. Improving the documentation on the tool via the [http://pragprog.com/book/hwcuc/the-cucumber-book "The Cucumber Book"] being one of them. The book continues to be revised to keep up with the rapidly evolving tool. Currently, Cucumber tests run on JVMs through JRuby. But to overcome the inherent latency, the team is working on a native Java implementation of the tool which can be built in to the Java development environment. During this adaptation to Java, the team also found aspects of the Ruby implementation that could be improved to make it much more flexible.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Further reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T01:12:53Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction'''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides [http://www.debian.org/doc/manuals/intro-i18n/ i18n] language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium].

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''On Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

===='''Given/When/Then + And/But construct'''====

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre-conditions of [http://en.wikipedia.org/wiki/Use_case Usecase].

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple English is what makes it unique letting clients who are not aware of the technicalities of a system, voice their opinion in the development process and hence the development is always in sync with the requirement.

=='''Ongoing developments'''==
Cucumber has rapidly become one of the most preferred tools for automated testing. Aslak Hellesoy and his team are working on further advancements and improvements to the tool. Improving the documentation on the tool via the [http://pragprog.com/book/hwcuc/the-cucumber-book "The Cucumber Book"] being one of them. The book continues to be revised to keep up with the rapidly evolving tool. Currently, Cucumber tests run on JVMs through JRuby. But to overcome the inherent latency, the team is working on a native Java implementation of the tool which can be built in to the Java development environment. During this adaptation to Java, the team also found aspects of the Ruby implementation that could be improved to make it much more flexible.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Further reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T01:11:19Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction'''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides [http://www.debian.org/doc/manuals/intro-i18n/ i18n] language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium].

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''On Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

===='''Given/When/Then + And/But construct'''====

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre-conditions of [http://en.wikipedia.org/wiki/Use_case Usecase].

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple English is what makes it unique letting clients who are not aware of the technicalities of a system, voice their opinion in the development process and hence the development is always in sync with the requirement.

=='''Ongoing developments'''==
Cucumber has rapidly become one of the most preferred tools for automated testing. Aslak Hellesoy and his team are working on further advancements and improvements to the tool. Improving the documentation on the tool via the [http://pragprog.com/book/hwcuc/the-cucumber-book "The Cucumber Book"] being one of them. The book continues to be revised to keep up with the rapidly evolving tool. Currently, Cucumber tests run on JVMs through JRuby. But to overcome the inherent latency, the team is working on a native Java implementation of the tool which can be built in to the Java development environment. During this adaptation to Java, the team also found aspects of the Ruby implementation that could be improved to make it much more flexible.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Further reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T01:05:08Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction'''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''On Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

===='''Given/When/Then + And/But construct'''====

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple English is what makes it unique letting clients who are not aware of the technicalities of a system, voice their opinion in the development process and hence the development is always in sync with the requirement.

=='''Ongoing developments'''==
Cucumber has rapidly become one of the most preferred tools for automated testing. Aslak Hellesoy and his team are working on further advancements and improvements to the tool. Improving the documentation on the tool via the [http://pragprog.com/book/hwcuc/the-cucumber-book "The Cucumber Book"] being one of them. The book continues to be revised to keep up with the rapidly evolving tool. Currently, Cucumber tests run on JVMs through JRuby. But to overcome the inherent latency, the team is working on a native Java implementation of the tool which can be built in to the Java development environment. During this adaptation to Java, the team also found aspects of the Ruby implementation that could be improved to make it much more flexible.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Further reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:54:16Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction'''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''On Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

===='''Given/When/Then + And/But construct'''====

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple English is what makes it unique letting clients who are not aware of the technicalities of a system, voice their opinion in the development process and hence the development is always in sync with the requirement.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Further reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:51:30Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''On Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

===='''Given/When/Then + And/But construct'''====

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple English is what makes it unique letting clients who are not aware of the technicalities of a system, voice their opinion in the development process and hence the development is always in sync with the requirement.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:50:28Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''On Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature steps
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

==='''Given/When/Then + And/But construct'''===

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple English is what makes it unique letting clients who are not aware of the technicalities of a system, voice their opinion in the development process and hence the development is always in sync with the requirement.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:41:53Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature steps
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

==='''Given/When/Then + And/But construct'''===

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple English is what makes it unique letting clients who are not aware of the technicalities of a system, voice their opinion in the development process and hence the development is always in sync with the requirement.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:40:55Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature steps
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

==='''Given/When/Then + And/But construct'''===

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
The advantages of Cucumber are that it mandates a person to spend more time in the planning phase before directly getting into the complexities of models, views and controllers. It lets one have a broader perspective of the application one intends to develop.
The syntax which is in simple english is what makes it unique letting clients who are not aware of the technicalities of a sytem, voice their opinion in the development process and hence the development is always in synch with the requirement.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:35:07Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber testing comprises of two components namely
*Feature steps
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

==='''Given/When/Then + And/But construct'''===

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
Cucumber was developed in order to involve clients and stakeholders in the development process. We could be dealing with people who may not be technically minded or whose experience of the web may only be lolcats. As great as that may be, asking them to imagine filling out a couple of forms online before making sure we are meeting their requirements is a bit much

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:34:08Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber comprises of two components namely
*Feature steps
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

==='''Given/When/Then + And/But construct'''===

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
Cucumber was developed in order to involve clients and stakeholders in the development process. We could be dealing with people who may not be technically minded or whose experience of the web may only be lolcats. As great as that may be, asking them to imagine filling out a couple of forms online before making sure we are meeting their requirements is a bit much

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:33:28Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''How Cucumber works''' ==
Cucumber comprises of two components namely
*Feature steps
*Step Definitions

==='''Features'''===
Features are essentially outward facing in the sense that they describe the ideal outcome given a state of the system. A given state of the system is the cumulative input to the system comprising of the events taking place in the given context and the predefined variables. Each feature is a collection of scenarios. The scenarios each are described by the given/when/then + and/but construct. Features are also known as '''matcher''' methods and are integral link to the step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario.

=== Given/When/Then + And/But construct

'''Given''' :
Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.

'''When''':
This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.

'''Then''':
This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.

'''And/But''':
These are used when there are multiple given conditions for which some actions need to be performed.

An Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

==='''Step Definitions'''===
Step definitions are primarily inward facing as they map the outward facing scenario statements with the inner Ruby code snippets. Step definitions either consists of keyword, string or regular expression. The mapping is mostly done by expression matching and calling the appropriate code snippets in the Ruby code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
Cucumber was developed in order to involve clients and stakeholders in the development process. We could be dealing with people who may not be technically minded or whose experience of the web may only be lolcats. As great as that may be, asking them to imagine filling out a couple of forms online before making sure we are meeting their requirements is a bit much

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:23:33Z

Ggsingh: /* Advantages */

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''Gherkin - the language Cucumber understands'''==

=='''How Cucumber works''' ==
Cucumber comprises of 3 components namely
*Feature
*Scenario
*implementation

'''Features''':
It is a collection of scenarios written in Gherkin. Scenarios basically start with the keyword “Scenarios” and each having keywords like Given/When/Then/And or But. These are also known as matcher methods and are an integral part of the step definitions popularly known as step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario. Step definitions either consists of keyword, string or regular expression.

'''Given''' : Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.
'''When''': This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.
'''Then''': This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.
'''And/But''': These are used when there are multiple given conditions for which some actions need to be performed. Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
Since most of the time the clients are people who are not from a technical background, Cucumber gives the flexibility to the stakeholders to voice their opinion in the development process and specify the pre-requisites of a system in simple language without getting into the technicalities of the system.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:21:17Z

Ggsingh: /* Advantages */

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''Gherkin - the language Cucumber understands'''==

=='''How Cucumber works''' ==
Cucumber comprises of 3 components namely
*Feature
*Scenario
*implementation

'''Features''':
It is a collection of scenarios written in Gherkin. Scenarios basically start with the keyword “Scenarios” and each having keywords like Given/When/Then/And or But. These are also known as matcher methods and are an integral part of the step definitions popularly known as step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario. Step definitions either consists of keyword, string or regular expression.

'''Given''' : Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.
'''When''': This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.
'''Then''': This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.
'''And/But''': These are used when there are multiple given conditions for which some actions need to be performed. Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
Cucumber was developed so that the stakeholders could voice their opinion in the development process.Cucumber gives the flexibility to the stakeholders to be a part of the system development and specify the pre-requisites of a system in simple language without getting into the technicalities of the system.

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:11:06Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use. With the libraries and drivers provided by Capybara for deploying web applications and for interacting with service applications, the testing requires minimum amount of coding.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''Gherkin - the language Cucumber understands'''==

=='''How Cucumber works''' ==
Cucumber comprises of 3 components namely
*Feature
*Scenario
*implementation

'''Features''':
It is a collection of scenarios written in Gherkin. Scenarios basically start with the keyword “Scenarios” and each having keywords like Given/When/Then/And or But. These are also known as matcher methods and are an integral part of the step definitions popularly known as step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario. Step definitions either consists of keyword, string or regular expression.

'''Given''' : Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.
'''When''': This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.
'''Then''': This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.
'''And/But''': These are used when there are multiple given conditions for which some actions need to be performed. Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
Cucumber was developed in order to involve clients and stakeholders in the development process. We could be dealing with people who may not be technically minded or whose experience of the web may only be lolcats. As great as that may be, asking them to imagine filling out a couple of forms online before making sure we are meeting their requirements is a bit much

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:06:33Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''Gherkin - the language Cucumber understands'''==

=='''How Cucumber works''' ==
Cucumber comprises of 3 components namely
*Feature
*Scenario
*implementation

'''Features''':
It is a collection of scenarios written in Gherkin. Scenarios basically start with the keyword “Scenarios” and each having keywords like Given/When/Then/And or But. These are also known as matcher methods and are an integral part of the step definitions popularly known as step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario. Step definitions either consists of keyword, string or regular expression.

'''Given''' : Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.
'''When''': This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.
'''Then''': This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.
'''And/But''': These are used when there are multiple given conditions for which some actions need to be performed. Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''Advantages'''==
Cucumber was developed in order to involve clients and stakeholders in the development process. We could be dealing with people who may not be technically minded or whose experience of the web may only be lolcats. As great as that may be, asking them to imagine filling out a couple of forms online before making sure we are meeting their requirements is a bit much

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:03:58Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
==='''Generic installation'''===

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

==='''Steps for Installation of Cucumber for Ruby on Rails 3.x'''===

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''Gherkin - the language Cucumber understands'''==

=='''How Cucumber works''' ==
Cucumber comprises of 3 components namely
*Feature
*Scenario
*implementation

'''Features''':
It is a collection of scenarios written in Gherkin. Scenarios basically start with the keyword “Scenarios” and each having keywords like Given/When/Then/And or But. These are also known as matcher methods and are an integral part of the step definitions popularly known as step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario. Step definitions either consists of keyword, string or regular expression.

'''Given''' : Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.
'''When''': This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.
'''Then''': This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.
'''And/But''': These are used when there are multiple given conditions for which some actions need to be performed. Example:

Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-04T00:00:08Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development(BDD)] which is derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as [http://en.wikipedia.org/wiki/JRuby JRuby], alternative application frameworks such as [http://www.sinatrarb.com/ Sinatra], other programming languages such as [http://www.python.org Python], test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and [http://seleniumhq.org/projects/ide/ Selenium]. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of [http://rspec.info/ RSpec]'s "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glitches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contributing to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
'''Generic installation'''

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

'''Steps for Installation of Cucumber for Ruby on Rails 3.x'''

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''Gherkin - the language Cucumber understands'''==

=='''How Cucumber works''' ==
Cucumber comprises of 3 components namely
*Feature
*Scenario
*implementation

Features:
It is a collection of scenarios written in Gherkin. Scenarios basically start with the keyword “Scenarios” and each having keywords like Given/When/Then/And or But. These are also known as matcher methods and are an integral part of the step definitions popularly known as step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario. Step definitions either consists of keyword, string or regular expression.

Given : Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.
When: This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.
Then: This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.
And/But: These are used when there are multiple given conditions for which some actions need to be performed.
Eg: Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

Implementations are generally steps written in Ruby for realizing the features. Each scenario has its equivalent block of Ruby Code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd
*http://jimmyzimmerman.com/blog/2008/05/intro-to-story-runner-and-bdd.html

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:54:58Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin '''Gherkin'''], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as JRuby, alternative application frameworks such as Sinatra, other programming languages such as Python, test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and Selenium. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
'''Generic installation'''

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

'''Steps for Installation of Cucumber for Ruby on Rails 3.x'''

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''Gherkin - the language Cucumber understands'''==

=='''How Cucumber works''' ==
Cucumber comprises of 3 components namely
*Feature
*Scenario
*implementation

Features:
It is a collection of scenarios written in Gherkin. Scenarios basically start with the keyword “Scenarios” and each having keywords like Given/When/Then/And or But. These are also known as matcher methods and are an integral part of the step definitions popularly known as step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario. Step definitions either consists of keyword, string or regular expression.

Given : Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.
When: This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.
Then: This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.
And/But: These are used when there are multiple given conditions for which some actions need to be performed.
Eg: Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

Implementations are generally steps written in Ruby for realizing the features. Each scenario has its equivalent block of Ruby Code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:53:22Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin Gherkin], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as JRuby, alternative application frameworks such as Sinatra, other programming languages such as Python, test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and Selenium. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
'''Generic installation'''

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

'''Steps for Installation of Cucumber for Ruby on Rails 3.x'''

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''Gherkin - the language Cucumber understands'''==

=='''How Cucumber works''' ==
Cucumber comprises of 3 components namely
*Feature
*Scenario
*implementation

Features:
It is a collection of scenarios written in Gherkin. Scenarios basically start with the keyword “Scenarios” and each having keywords like Given/When/Then/And or But. These are also known as matcher methods and are an integral part of the step definitions popularly known as step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario. Step definitions either consists of keyword, string or regular expression.

Given : Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.
When: This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.
Then: This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.
And/But: These are used when there are multiple given conditions for which some actions need to be performed.
Eg: Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

Implementations are generally steps written in Ruby for realizing the features. Each scenario has its equivalent block of Ruby Code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''References'''==
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:50:00Z

Ggsingh:

=Cucumber and Capybara=

=='''Introduction '''==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable [http://en.wikipedia.org/wiki/Domain-specific_language domain-specific language(DSL)], most widely used is [https://github.com/cucumber/cucumber/wiki/Gherkin Gherkin], although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as JRuby, alternative application frameworks such as Sinatra, other programming languages such as Python, test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and Selenium. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

=='''History and the need for development'''==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

=='''Setting up Cucumber'''==
'''Generic installation'''

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

'''Steps for Installation of Cucumber for Ruby on Rails 3.x'''

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

=='''Gherkin - the language Cucumber understands'''==

=='''How Cucumber works''' ==
Cucumber comprises of 3 components namely
*Feature
*Scenario
*implementation

Features:
It is a collection of scenarios written in Gherkin. Scenarios basically start with the keyword “Scenarios” and each having keywords like Given/When/Then/And or But. These are also known as matcher methods and are an integral part of the step definitions popularly known as step definitions. Now when Cucumber is executed the corresponding block of Ruby code is invoked. Scenarios are independent of each other and once a scenario execution is over there is nothing which is carried over to the next scenario. Step definitions either consists of keyword, string or regular expression.

Given : Purpose of given is to create a setting for user interaction with the system. These are analogous to the pre conditions of usecase.
When: This for the main actions the user performs ‘given’ a scenario i.e. transition of state which has an observable effect.
Then: This is majorly to check the consequences of the action performed by the user i.e. what is the output of the system when a particular input is given.
And/But: These are used when there are multiple given conditions for which some actions need to be performed.
Eg: Scenario: Manifold Givens
Given the username
And Given the password
When I press enter
Then I see the username on the screen
But I do not see the password on the screen

Implementations are generally steps written in Ruby for realizing the features. Each scenario has its equivalent block of Ruby Code.

=='''Setting up Capybara''' ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

=='''Example of running Cucumber tests on Capybara'''==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

'''Features and Scenarios''': As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

'''Step Definitions''': As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

'''Class definition''': This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

=='''References'''==
[ref/]
*http://cukes.info/
*http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
*http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/
*http://railscasts.com/episodes/155-beginning-with-cucumber
*http://rubysource.com/smelly-cucumbers/

=='''Suggested Further Reading'''==
*http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:47:45Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:47:13Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:46:31Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:46:12Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:43:37Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:43:07Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:37:47Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:34:56Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:34:05Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:33:08Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:31:57Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:25:28Z

Ggsingh:

=Cucumber and Capybara=

== Introduction ==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable domain-specific language(DSL), most widely used is Gherkin, although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as JRuby, alternative application frameworks such as Sinatra, other programming languages such as Python, test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and Selenium. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

== History and the need for development ==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

== Setting up Cucumber ==
'''Generic installation'''

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

'''Steps for Installation of Cucumber for Ruby on Rails 3.x'''

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

== Gherkin - the language Cucumber understands ==

== How Cucumber works ==

== Setting up Capybara ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

== Example of running Cucumber tests on Capybara ==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

Features and Scenarios: As discussed above, the features ... In the example below, the feature describes a scenario within a banking system where a student needs to test the system's ability to find the simple interest on a given principal at a given rate per year.

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principal
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

Step Definitions: As discussed before, the step definitions provided the mapping for the corresponding code snippets that each scenario within the feature interacts with. In this example, for the givens, we first create an object of the class Interest_calc and push the arguments into the instance. Then for when, we call the corresponding method that calculates the interest. For the then, we display the result on the screen.

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

Class definition: This is the Interest_calc class that is accessed in the step definition.

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

== References ==
http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T23:15:20Z

Ggsingh:

=Cucumber and Capybara=

== Introduction ==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable domain-specific language(DSL), most widely used is Gherkin, although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as JRuby, alternative application frameworks such as Sinatra, other programming languages such as Python, test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and Selenium. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

== History and the need for development ==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

== Setting up Cucumber ==
'''Generic installation'''

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

'''Steps for Installation of Cucumber for Ruby on Rails 3.x'''

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

== Gherkin - the language Cucumber understands ==

== How Cucumber works ==

== Setting up Capybara ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

== Example of running Cucumber tests on Capybara ==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment. It is also possible to use the Capybara DSL for writing the tests but the most widely used DSL is Gherkin. The example below uses Gherkin but it can be easily transformed using the DSL provided by Capybara.

Features and Scenarios:

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principle
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

Step Definitions:

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

Class definition:

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T22:58:46Z

Ggsingh:

=Cucumber and Capybara=

== Introduction ==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable domain-specific language(DSL), most widely used is Gherkin, although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as JRuby, alternative application frameworks such as Sinatra, other programming languages such as Python, test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and Selenium. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

== History and the need for development ==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

== Setting up Cucumber ==
'''Generic installation'''

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

'''Steps for Installation of Cucumber for Ruby on Rails 3.x'''

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

== Gherkin - the language Cucumber understands ==

== How Cucumber works ==

== Setting up Capybara ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

== Example of running Cucumber tests on Capybara ==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment.

Features and Scenarios:

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principle
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

Step Definitions:

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

Class definition:

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T22:55:59Z

Ggsingh:

=Cucumber and Capybara=

== Introduction ==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable domain-specific language(DSL), most widely used is Gherkin, although you can use testing environment specific languages also like the Capbara DSL

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as JRuby, alternative application frameworks such as Sinatra, other programming languages such as Python, test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment. It carries all the information about the driver running the test and comes with a built in support for Rack::Test and Selenium. It requires no explicit setting up

'''Capybara''' is a testing environment that simulates the manner in which a real world user would interact with the application. It requires no explicit setup for Rails applications. The most powerful feature of Capybara is that it has a very intuitive application program interface that understands any language an actual user would use.

== History and the need for development ==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

== Setting up Cucumber ==
'''Generic installation'''

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

'''Steps for Installation of Cucumber for Ruby on Rails 3.x'''

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

== Gherkin - the language Cucumber understands ==

== Cucumber "Features" and "Scenarios" ==

== Cucumber "Step Definitions" ==

== Setting up Capybara ==
As explained before, Capybara doesn't require explict set up for Rails applications.
For Rails, we add the following line to the test helper file:
require 'capybara/rails'

== Example of running Cucumber tests on Capybara ==
After setting up cucumber-rails and Capybara as described above, the following example describes how an actual cucumber test is written and run in the Capybara environment.

Features and Scenarios:

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principle
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

Step Definitions:

require 'capybara/cucumber'
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

Class definition:

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T22:41:29Z

Ggsingh:

=Cucumber and Capybara=

== Introduction ==
'''Cucumber''' is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable domain-specific language(DSL) known as Gherkin.

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as JRuby, alternative application frameworks such as Sinatra, other programming languages such as Python, test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment

'''Capybara'''

== History and the need for development ==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

== Setting up Cucumber ==
'''Generic installation'''

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

'''Steps for Installation of Cucumber for Ruby on Rails 3.x'''

Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

== Gherkin - the language Cucumber understands ==

== Cucumber "Features" and "Scenarios" ==

== Cucumber "Step Definitions" ==

== Setting up Capybara ==

== Example of running Cucumber tests on Capybara ==

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principle
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

Step Definitions:

begin require 'rpec/expectations';
rescue LoadError;
require 'spec/expectations';
end
require 'cucumber/formatter/unicode'
$:.unshift(File.dirname(_FILE_) + '/../../lib')
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

Class def:

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T22:34:24Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T22:31:23Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T22:30:47Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T22:29:17Z

Ggsingh:

=Cucumber and Capybara=

== Introduction ==
Cucumber is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable domain-specific language(DSL) known as Gherkin.

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

Cucumber provides support for a wide range of Ruby virtual machines such as JRuby, alternative application frameworks such as Sinatra, other programming languages such as Python, test environments such as Capybara and provides i18n language support for feature and step files.

This article primarily focuses on running Cucumber tests on the Capybara testing environment

Capybara

== History and the need for development ==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks

== Setting up Cucumber ==

Install Ruby on the system

gem install cucumber

To read up on more information about this gem

cucumber --help

Steps for Installation of Cucumber for Ruby on Rails 3.x
Cucumber-Rails is used for performing Cucumber tests on Rails.

Step 1 : Add the following to the Gem File

group :test do
gem 'cucumber-rails', :require => false
# database_cleaner is not required, but highly recommended
gem 'database_cleaner'
end

Step 2 : Then install the gem

bundle install

Step 3 : Bootstrap your Rails app by

rails generate cucumber:install

== Example ==

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principle
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

Step Definitions:

begin require 'rpec/expectations';
rescue LoadError;
require 'spec/expectations';
end
require 'cucumber/formatter/unicode'
$:.unshift(File.dirname(_FILE_) + '/../../lib')
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

Class def:

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T22:08:52Z

Ggsingh:

=Cucumber and Capybara=

== Introduction ==
Cucumber is one of the latest additions to the RSpec family of tools for testing in Ruby. Testing is one of the most important parts of the Ruby culture. It allows programmers and software development teams to describe feature based tests in plain text definitions known as "stories". This text is written in a business readable domain-specific language(DSL) known as Gherkin.

Though Cucumber is a testing tool, the main intent of its development is to support Behavior Driven Development(BDD) which is derived from Test Driven Development. This implies that the tests written in DSL are typically written before any other part of the code is written. It is analysed by the non technical stakeholders and then the production code is written. The production code is thus written outside-in, in such a way that the tests pass.

== History and the need for development ==

Cucumber is actually Aslak Hellesoy's revamp of RSpec's "Story Runner"(by Dan North). The earlier versions of "Story Runner" and its predecessor RBehave required that the stories be written in Ruby. But seeing the associated inconvenience, David Chelimsky added the plain text support with contributions done from an eclectic support team.

In April 2008, Aslak Hellesoy started the Cucumber project to iron out the inherent flaws and glictches of the RSpec Story Runner. Joseph Wilk and Ben Mabey were the regular contributors to the project. Matt Wynne joined in September 2009. In October 2009, Mike Sassak and Gregory Hnatiuk did some great work on a faster parser for Cucumber. In addition to the core team, there were over 250 developers contirbuting to the overall development of the project.

Though Cucumber is written in Ruby, it can be used to test code written in Ruby and other languages too. Not limited to Java, C# and Python. It required minimal use of Ruby and is hence believed to be extremely easy to code. Moreover, the user stories for the features can be written in any human language.

Ever since, Cucumber has seen a lot of revision and refactoring. One of the major refactoring include transferring certain implementation portions to make it customized for particular frameworks
== Example ==

# Language: English
Feature: InterestCalc
In order to avoid an error in interest calculation
As a new student
I want to be told the interest for given principal per year
Scenario: Interest on Principle
* I have entered 1000 into the interest_calc
* I have entered 3.5 into the interest_calc
* I press calc
* The result should 35 on the screen

Step Definitions:

begin require 'rpec/expectations';
rescue LoadError;
require 'spec/expectations';
end
require 'cucumber/formatter/unicode'
$:.unshift(File.dirname(_FILE_) + '/../../lib')
require 'Interest_calc'
Given /I have entered (.*) into the interest_calc/ do |n|
@calci=Interest_calc.new
@calci.setdata(n)
end
When /I press (\w+)/ do |op|
@result=@calci.calc
end
Then /the result should be (.*) on the screen/ do |result|
@result.should == result.to_f
end

Class def:

class Interest_calc
def push(n)
@args ||= []
@args<<n
end
def calc
@args.inject(0){|p,r| p=p*r/100}
end
end

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T21:49:43Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T21:48:04Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T21:45:42Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T21:44:38Z

Ggsingh:

CSC/ECE 517 Fall 2012/ch1b 1w71 gs

2012-10-03T21:38:57Z

Ggsingh: