Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-11-06T01:39:59Z

Payyapp: /* Basic Object Oriented Concepts */

='''Introduction to Object Oriented Design(OOD)'''=

This page serves as a knowledge source for understanding the concepts covered in Lecture14- [http://en.wikipedia.org/wiki/Object-oriented_design Introduction to Object Oriented Design(OOD)]. 

__TOC__

= Overview =
Lecture 14 <ref name="CSC517">[http://courses.ncsu.edu/csc517//common/lectures/notes/lec14.pdf OOD], CSC 517 Lecture14</ref> of CSC 517 covered various aspects of the [http://en.wikipedia.org/wiki/Object-oriented_design object oriented design] including the basics of OOD principles along with the design criteria and the [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class Responsibility Collaboration card] tool.

Object-oriented design can be defined as the process of planning a 'system of interacting objects' for the purpose of solving a software problem. It is one approach to software design that revolves around the basic entity called [http://en.wikipedia.org/wiki/Object_(computer_science) object]. An object contains data and procedures grouped together to represent an entity(class). Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis.

= Basic Object Oriented Concepts =
The five basic concepts of object-oriented design are the implementation level features that are built into the programming language. They can be considered as the general vocabulary required to implement an object oriented design solution <ref name="OOD vocabulary">[http://www.beroux.com/english/articles/oop_uml_and_rup.php OOD Vocabulary], OOD Vocabulary</ref>. These terms are explained in brief:

*[http://en.wikipedia.org/wiki/Class_(computer_programming) Class]: A ''class'' is a tight coupling or association of data structures with the methods or functions that act on the data.A class defines constituent members which enable these class instances to have state and behavior.

*[http://en.wikipedia.org/wiki/Object_(computer_science) Object]: An ''object'' is an instance of the class serving a separate function. An object is defined by its properties.

*[http://en.wikipedia.org/wiki/Information_hiding Information Hiding/Encapsulation]: The ability to protect some components of the object from external entities i.e. protecting parts of the program from extensive modification if the design decision is changed. This is achieved by language keywords to enable a variable to be declared as ''private'' or ''protected'' to the owning ''class''.

*[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]: inheritance is a way to reuse code of existing objects and thus ability for a ''class'' to extend or override functionality of another ''class''. Inheritance is realized by establishing a subtype from an existing object, or both, depending upon programming language support.

*[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism]: The ability to replace an ''object'' with its ''subobjects''. The ability of an ''object-variable'' to contain, not only that ''object'', but also all of its ''subobjects''.

*[http://en.wikipedia.org/wiki/Interface_(computer_science) Interface]: Interface can be defined as the ability to defer the implementation of a ''method'' or the process to define the ''functions'' or ''methods'' signatures without implementing them.

= Criteria for Elegant Software Design =
Listed below are the different criteria for elegant software design. There are nine different design considerations, out of which the first five address correctness of the software and the rest consider the performance.

[http://en.wikipedia.org/wiki/Usability Usability]: Usability can be measured by the ease of use for the client.

'''Completeness''': A software program/application is complete if it solves all the client needs.

'''Robustness''': A good design is one that can deal with unusual situations gracefully and avoid crashing.

'''Efficiency''': The application performs the necessary computations in a reasonable amount of time.

'''Scalability''': An application is scalable if it performs correctly and efficiently when the problems grow in size by several orders of magnitude.

'''Readability''': If it is easy for another programmer to read and understand the design and code, the design is readable.

'''Modifiability''': If the software can easily be enhanced or restricted by adding new features or removing old features without breaking existing code, the design is modifiable.

'''Reusability''': Resuability checks the ability to be reused in another completely different setting.

'''Simplicity''': The simplicity criteria check if the design and/or the implementation unnecessarily complex.

= Design Concepts =
Listed below are the major components for building a design solution for a problem:
* Defining objects, creating [http://en.wikipedia.org/wiki/Class_diagram class diagram] from conceptual models and map the entities to classes.

* Identifying attributes for each class/entity.

* Use [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design patterns] <ref name="Design Patterns">[http://www.uml.org.cn/c++/pdf/DesignPatterns.pdf Design Patterns Elements of Reusable Object Oriented Software by Erich Gamma]</ref> to solve a problem that can be used in many different situations and/or applications.

* Identifying persistent objects i.e. to know objects that last longer than a single runtime.

* Identify the [http://en.wikipedia.org/wiki/Application_framework application framework] to take advantage of the existing code and reuse whatever possible.

=Design Principles =
Listed below are the main principles that need to be followed for building an effective design solution<ref name="Design Principles">[http://www.oodesign.com/design-principles.html Object Oriented Design Principles]</ref>:

* [http://en.wikipedia.org/wiki/Open/closed_principle Open Close Principle]: This principle states that software entities like classes, modules and functions should be open for extension but closed for modifications.

* [http://en.wikipedia.org/wiki/Dependency_inversion_principle Dependency Inversion Principle]: This principle states that high-level modules should not depend on low-level modules and both should depend on abstractions.

* [http://en.wikipedia.org/wiki/Interface_segregation_principle Interface Segregation Principle]: This principle states that clients should not be forced to depend upon interfaces that they do not use.

* [http://en.wikipedia.org/wiki/Single_responsibility_principle Single Responsibility Principle]: This principle states that a class should have only reason to change.

* [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov's Substitution Principle]: This principle states that derived types must be completely substitutable for their base types.

= OOD: The CRC Method =
[http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card Class-Responsibility-Collaboration card] is a very useful tool for software design that determine the [http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card classes] needed along with the types of interactions.

CRC cards are created from [http://en.wikipedia.org/wiki/Index_card index card]s on which are written:

# The class name
# Its Super and Sub classes (if applicable)
# The responsibilities of the class.
# The names of other classes with which the class will collaborate to fulfill its responsibilities.
# Author

The use of small card minimizes the complexity of the design. It forces the designer to refrain from giving the class too many responsibilities. These cards are portable and thus can easily be laid out on a table and re-arranged while discussing the design with other people.

A specification for the program being designed is studied and then the cards that need to be created are designed. The cards contain the class names(generally nouns) along with the responsibilities(verbs) and the collaborators associated with the class. When choosing classes, we need to make sure that the class name,

#is a singular noun,
#does not really have the same functionality as some other class,
#is not simply a primitive type,(because u need not write code for primitive types)

== Example 1: Flight reservation system ==

''Requirements for the Flight Reservation System '' 
* The mission is to allow round-trip airline ''tickets'' to be bought over the Web. 
* Each ''customer'' specifies an origination ''airport'', a destination airport, and dates for outbound and return ''flights''. 
* The customer reserves one ''outbound flight'' and one ''return flight'' from a menu presented by the system. 
* Each choice that the system presents consists of one or more flight ''segments'' (there may be a change of planes). 
* The customer may buy tickets for one or more ''passengers''. 
* No more tickets can be sold for a flight than there are ''seats'' on the ''plane''. 
* Each passenger is assigned to a specific seat. 
* The system calculates the total ''cost'' of the tickets by adding the cost of the individual segments. 
*If dissatisfied with the cost, the customer may select ''alternate flights''. 
* After a customer has bought a ticket, (s)he will be e-mailed a ''confirmation'' 

Some class names for the present scenario are 

Customer 
Flight 
Airport 
Segment 
Ticket 
Cost 

Some nouns that are not classes are 

Seats 
Alternate Flights 
Outbound Flight 
Inbound Flight 

Some of the responsibilities of the Customer class and their collaborators are 
* to make payment(R) shopping cart(C)
* to choose the flight(R) Flight Segment(C)

== Example 2: Address Book ==
Requirements Statements 
The software to be designed is a program that can be used to maintain an address book. An address book holds a collection of entries, each recording a person's first and last names, address, city, state, zip, and phone number.

It must be possible to add a new person to an address book, to edit existing information about a person (except the person's name), and to delete a person. It must be possible to sort the entries in the address book alphabetically by last name (with ties broken by first name if necessary), or by ZIP code (with ties broken by name if necessary). It must be possible to print out all the entries in the address book in "mailing label" format.

It must be possible to create a new address book, to open a disk file containing an existing address book to close an address book, and to save an address book to a disk file, using standard New, Open, Close, Save and Save As ... File menu options. The program's File menu will also have a Quit option to allow closing all open address books and terminating the program.

The initial requirements call for the program to only be able to work with a single address book at a time; therefore, if the user chooses the New or Open menu option, any current address book will be closed before creating/opening a new one. A later extension might allow for multiple address books to be open, each with its own window which can be closed separately, with closing the last open window resulting in terminating the program. In this case, New and Open will result in creating a new window, without affecting the current window.

The program will keep track of whether any changes have been made to an address book since it was last saved, and will offer the user the opportunity to save changes when an address book is closed either explicitly or as a result of choosing to create/open another or to quit the program.

The program will keep track of the file that the current address book was read from or most recently saved to, will display the file's name as the title of the main window, and will use that file when executing the Save option. When a New address book is initially created, its window will be titled "Untitled", and a Save operation will be converted to Save As ... - i.e. the user will be required to specify a file.<ref name="Address Book Example">[http://www.cs.gordon.edu/courses/cs211/AddressBookExample/Requirements.html Address Book Example]</ref>

The class names for the present scenario are 

User 
AddressBook 
FileSystem 
AddressBookController 
Person 
AddressBookGUI 

The responsibilities of some of the classes and their collaborators are 
'''Person''' 
Responsibilities 
*Create a new object,given an individual's name,address,city,state,ZIP, and phone 
*Furnish the individual's first name 
*Furnish the individual's last name 
*Furnish the individual's address 
*Update the stored information(except the name) about an individual 

There are no collaborators for this class 

'''File System''' 
Responsibilities 
Read a stored address book from a file,given its file name 
Save an adddress book to a file,given its file name 

The collaborator for both the responsibilities is 
AddressBook 

== Example 3: Course Registration ==
''Requirements for the Course Registration System'' 
* The mission is to automate registration of students for courses at a university. 
* Each ''student'' takes one or more courses, which are identified by name and course number. 
* Each ''course'' is worth one or more ''credit hours''. 
* A student can register for up to 21 credit hours. 
* For each course that is taught, the students are placed into ''sections'', which may meet at different times and be taught by different instructors. 
* If more than 50 students want to take the same ''class'', another section will be added. 
* If fewer than 5 students register for a section, it will be canceled. 
* If no ''instructor'' can be persuaded (or hired) to teach a class, it will be canceled. 
* Students may specify alternate courses or sections, in case of a time ''conflict'', or if their first-choice class is canceled. 
* After a student has registered for courses, (s)he will be e-mailed a class ''schedule''. 

Some class names for the present scenario are 

Instructor 
Student 
schedule 
class 
Course 

Some of the responsibilities of the Customer class and their collaborators are

Instructor(C) offer course(sections)(R)

Student(C) takesCourse(R) Course(Colloborators)

== Example 4: Other Example ==
''Requirements for the bus navigator system'': 
* The mission is to allow ''students'' to plan trips around NCSU and Raleigh by bus. 
* Each ''rider'' specifies an origination ''stop'' and a destination ''stop'' . 
* The system presents a list of departure times, arrival times, and transfer points, and a ''map'' of the ''trip''. 
* Each item on the list consists of one or more of trip ''segments''. 
* Each trip segment consists of a ''departure point'' and ''time'', and an ''arrival point'' and ''time''. 
* If it would significantly reduce the time of the trip, the system may suggest ''walking'' between two nearby stops. 
* Each segment may be on a ''Wolfline bus'', a ''CAT bus'', or a ''TTA bus''. 
* Each bus has a ''schedule'', which is a set of ''trips'', with each trip consisting of a set of ''stops'' and ''times''. 
* The ''fare'' is 0 on a Wolfline bus, $1 on a CAT bus, and $2 ($2.50 for express) on a TTA bus. 
* The system calculates the total ''cost'' of the trip by adding the cost of the individual segments. 

The class names for the present scenario are 
stop 
map 
segment 
walk 
bus 
Trip 

The responsibilities of the Trip class and their collaborators are 
Know your Stops(R)
Know your Stopping Times(R)

Stop(C)

=References=
<references />

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:40:26Z

Payyapp: /* Need for Design */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:40:10Z

Payyapp: /* Overview */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:36:31Z

Payyapp: /* OOD: The CRC Method */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:36:14Z

Payyapp: /* OOD: The CRC Method */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:35:02Z

Payyapp: /* OOD: The CRC Method */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:27:38Z

Payyapp: /* Design Principles */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:20:56Z

Payyapp: /* Design Concepts */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:15:22Z

Payyapp: /* Design Concepts */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:11:09Z

Payyapp: /* Design Concepts */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:10:43Z

Payyapp: /* Design Concepts */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:10:12Z

Payyapp: /* Design Concepts */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T14:09:35Z

Payyapp: /* Criteria for Elegant Software Design */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T13:58:23Z

Payyapp:

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T13:44:51Z

Payyapp: /* Basic Object Oriented Concepts */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T13:43:54Z

Payyapp: /* Basic Object Oriented Concepts */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T13:37:20Z

Payyapp: /* Basic Object Oriented Concepts */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T05:44:59Z

Payyapp: /* OOD: The CRC Method */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T05:43:50Z

Payyapp: /* OOD: The CRC Method */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T05:42:21Z

Payyapp: /* OOD: The CRC Method */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T05:41:59Z

Payyapp: /* OOD: The CRC Method */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T05:41:24Z

Payyapp: /* OOD: The CRC Method */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T05:09:06Z

Payyapp: /* Need for Design */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T04:59:17Z

Payyapp: /* Criteria for Elegant Software Design */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T04:58:47Z

Payyapp: /* Criteria for Elegant Software Design */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T04:58:06Z

Payyapp: /* Criteria for Elegant Software Design */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T04:55:24Z

Payyapp: /* Usability */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-30T04:40:15Z

Payyapp: /* Criteria for Elegant Software Design */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T20:58:47Z

Payyapp:

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T20:39:49Z

Payyapp: /* Overview */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T20:39:27Z

Payyapp: /* Overview */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T20:35:51Z

Payyapp: /* Overview */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T20:31:01Z

Payyapp: /* Overview */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T19:12:00Z

Payyapp: /* Overview */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T19:08:33Z

Payyapp:

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T19:07:39Z

Payyapp: /* Overview */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T19:03:11Z

Payyapp: /* Introduction */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T19:03:03Z

Payyapp: /* Introduction to Object Oriented Design(OOD) */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T19:02:53Z

Payyapp: /* Introduction to Object Oriented Design(OOD) */

CSC/ECE 517 Fall 2011/ch2 2e gp

2011-10-25T19:02:09Z

Payyapp: /* Testing Frameworks for Ruby */

='''Testing Frameworks for Ruby'''=

This page serves as a knowledge source for understanding the different Testing Frameworks available for [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]. 

__TOC__

= Introduction =
No code is perfect from the word go! Testing plays an important role in System Development Life Cycle. During testing, one follows a taxonomic procedure to uncover defects at various stages. A test framework provides various Test Types, Test Phases, Test Models, Test Metrics and acts as a guideline as to how to perform effective testing <ref> http://www.scribd.com/doc/15909730/Software-Testing-Framework </ref>. Various testing tools are available for [http://en.wikipedia.org/wiki/Ruby Ruby]language, each having some unique features over others. Here is a brief introduction and feature comparisons of popular testing frameworks.

== Testing Approaches ==
[[File:Capture5.JPG‎|thumb|right|200px|flow of test driven developmental approach]]
Before delving into testing for Ruby, in general, these are the followed approaches in industry today

=== Test Driven Development ===

This strategy, (abbreviated as TDD) <ref> http://en.wikipedia.org/wiki/Test-driven_development </ref>, though cumbersome due to its methodology develops efficient code. First a unit test is written for a function, even before the code for that function is developed. Based on this test minimal code is developed to ensure the test succeeds; if not the code is modified until test run successfully. In this iterative approach, effort is made to ensure flawless code is developed.

=== Behavior Driven Development ===
BDD <ref> http://en.wikipedia.org/wiki/Behavior_Driven_Development </ref> as its popularly know, upholds the traditional iterative workflow of Test Driven Development, but it focuses on defining behaviors that is easy to understand to naive people (with no programming background) by writing tests in natural language. This approach focuses more on looking at code development from a behavioral abstraction. For example testing the code for a recipe belonging to a category of a cookbook, in BDD would be something like 'A recipe can't be without a category'

= Unit Testing =
[http://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a method by which one can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written.
== Test::Unit ==
[[File:Capture4.JPG‎|thumb|right|400px|screen capture of TestUnit console in [http://en.wikipedia.org/wiki/RubyMine RubyMine IDE]]]

The in-built, ready to use unit testing mechanism for Ruby is called [http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit].It belongs to the XUnit family unit testing framework. It has a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests are bundled separately in a test class in the code it is aimed to test.
=== Features ===
This salient features of the Test::Unit Framework are:-
==== Assertions ====
One can use Test::Unit to make [http://en.wikipedia.org/wiki/Assertion_(computing) assertions]. The test is successful if the assertion is true and fails if the assertion is false. All the assertion methods provided by test::unit can be found at [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Test::Unit::Assertions].

{|border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

==== Test-Fixtures ====
Using a test fixture, one can initialize (and cleanup) the common set of data for two or more tests hence eliminating unnecessary duplication. Fixtures are written in the setup() and teardown() methods.
==== Test-Suite ====
As unit tests increase in number for a given project, it becomes tough running them one at a time. It is hence useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose<ref>http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/TestSuite.html</ref>.

=== Example Test ===
The Test::Unit::TestCase class is the main class and the BinarySearchTest is the subclass, it overrides setup and teardown methods. All test methods start with 'test_' prefix thus differentiating helper methods from main methods. The Test::Unit::TestCase class makes the test methods into tests, wrapping them into a suite and running the individual tests. The results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'english_french'
class EnglishFrenchTest < Test::Unit::TestCase
include EnglishFrenchTranslator
def test_simple_word
s = translate("house")
assert_equal("mason", s)
end
def test_word_beginning_with_vowel
s = translate("apple")
assert_equal("pomme", s)
end
def test_two_consonant_word
s = translate("stupid")
assert_equal("stupides", s)
end
end

The tests are run by running the file test_english_french.rb.Sample results for the above test is shown below.

$ ruby test_english_french.rb
Loaded suite test_english_french
Started
FFF
Finished in 0.01091 seconds.

3 tests, 3 assertions, 0 failures, 0 errors

== Shoulda ==
Shoulda is a library rather than a framework which gives the flexibility to write better and easy to understand tests for the Ruby application being tested. Shoulda compliments Test::Unit and RSpec in the sense that it can be used within both of them. Using Shoulda one can provide context to tests so that, tests can be grouped according to a specific feature or scenario.
===Features===

[[File:Capture1.JPG‎|thumb|left|170px|components of Shoulda]]

Shoulda consist of matchers, test-helpers and assertions<ref>http://rubydoc.info/gems/shoulda/2.11.3/frames</ref> -

'''Matchers''' 
Matchers (or more popularly simply [http://en.wikipedia.org/wiki/Macro_(computer_science)#Text_substitution_macros macros]) are Test::Unit- and RSpec-compatible one-liners that test common Rails functionality. The task of developing cumbersome, complex and often erroneous code is made simple with the help of matchers.

'''Helpers''' 
Helpers like ''#context'' and ''#should'' not only gives ''RSpec'' like test blocks in ''Test::Unit'' but also in addition to these, one gets nested contexts and a much more readable syntax.

'''Assertions''' 
Many common Rails testing idioms have been distilled into a set of useful assertions.

 

===Installation===
Shoulda for can be installed for [http://weblog.rubyonrails.org/2010/8/29/rails-3-0-it-s-done| Rails 3.0] version by including the following in the [http://gembundler.com/gemfile.html Gemfile]
<code>
group :test do
gem "shoulda"
gem "rspec-rails", "2.0.0.beta.12"
end
</code> 
===Example===

As far as usage of shoulda is concerned, one can write matchers as follows-

Suppose one is testing for the class ''Post'' on a blog, heres how it is achieved using shoulda::Macthers

<code>
class Post_Test < Test::Unit::TestCase
should belong_to(:user)
should have_many(:tags).through(:taggings) 
should validate_uniqueness_of(:title)
should validate_presence_of(:title)
should validate_numericality_of(:user_id)
end
</code>

Similarly the test for class ''Users'' can be

<code>
class Users_Test < Test::Unit::TestCase
should have_many(:posts) #checking validity of e-mail id 
should_not allow_value("blah").for(:email)
should allow_value("a@b.com").for(:email)
should_not allow_mass_assignment_of(:password)
end
</code>

As can be seen, writing test case for TDD becomes much more elegant and less error prone.

Similarly shoulda::helpers can be written as shown -

Suppose one wants to check the validity of getter method presence for an object, simply an should_have helper can be written like

<code>
context "the create action" do
setup do
@attributes = Posts.attributes_for(:item)
post :create, :item => @attributes
end 
should_create_row Item do |item|
assert_has_attributes @attributes, item #''assert_has_attributes'' - simply a helper method that makes sure the object has getter methods and values corresponding to the key/value pairs in the hash.
end
end
</code>

When this tests are run one gets the some similar following results

<code>
Loaded suite C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample
Started
...F...
Finished in 0.001000 seconds. 
1) Failure:
test: Users_Test Functions should Fail Test. (Post Test) [C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample.rb:33]:
<1> expected but was
<nil>. 
1 tests, 1 assertions, 1 failures, 0 errors, 0 skips 
Test run options: --seed 25476

</code>

The most interesting part of shoulda is the assertions which make writing test code efficient. An example of shoulda::Assertion can be seen as below

<code>
assert_same_elements([:a, :b, :c], [:c, :a, :b]) #checks whether array has same entries
assert_contains(['a', '1'], /\d/) #checks for presence of a digit
assert_contains(['a', '1'], 'a') #checks for presence of letter ''a''
</code>

== RSpec ==
[[File:Capture3.JPG‎|thumb|left|400px|flow of logic in R-Spec]]

RSpec is a Behavioral Driven development tool,created by Dave Astels and Steven Bake <ref>http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial</ref> aimed as test driven development.

RSpec is merging of two projects into one -

application level behaviour described by a Story Framework 
object level behaviour described by a Spec Framework 

The primary aim of RSpec is to drift the focus from unit testing to behavioral testing, i.e. to check if the desired functionality is achieved. It is also used to check for redundancy in code and helps refactoring our code without having to re-write every test.
===Installation===
In order to install RSpec, open a command shell, go to /bin folder in Ruby directory and type
> gem install rspec

===Features===
==== RSpec Story ====
A Story describes the functionality of a specific software feature, and it describes it in a way that is easy to understand from the point of view of a client. In fact a story can be thought of as a conversation between a client and a programmer over some feature of the software. The key points of a story are:- Title, Narrative, Scenario, Givens, Details[http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]
==== Message Expectations ====
A message expectation (a.k.a. mock method)<ref>http://rspec.info</ref> is an expectation that an object should receive a specific message during the execution of an example. This is similar to "Assertions" in test::unit.
==== Group ====
More than one executable example can be grouped into one file.
==== Spec File====
A spec file is a file that contains one or more group examples.
==== describe() and it() methods ====
The describe() method takes an arbitrary number of arguments and returns a sub-class of Spec::Example::ExampleGroup. The it() method takes a single String, an optional Hash and an optional block.

=== Example Test ===
The below code is an example for testing using rspec. The spec file, ruby file and the output are shown. It can be seen that code can be added to the spec file for different test conditions and expectations.

# archery_spec.rb
require 'archery'
describe Archery, "#score" do
it "returns 0 for all mock games" do
archery = Archery.new
20.times { archery.hit(0) }
archery.score.should == 0
end
end

# archery.rb
class Archery
def hit(arrows)
end
def score
0
end
end

$ spec archery_spec.rb --format nested
Archery#score
returns 0 for all mock games
Finished in 0.006535 seconds
1 example, 0 failures

== Cucumber ==
Cucumber is a testing tool that follows the BDD approach of testing. Cucumber written itself in Ruby programming language allows the execution of feature documentation written in natural language often termed as [http://en.wikipedia.org/wiki/User_story user stories]
=== Features of Cucumber ===

==== Terminology of Cucumber====
There are few taxonomy terms related to Cucumber <ref>http://cuke4ninja.com/sec_cucumber_jargon.html</ref> as follows-
[[File:Capture.JPG‎|thumb|left|200px|major components of Cucumber]]
'''Stakeholder''' - A person who gets some value out of the system like an administrator '''Feature''' - A feature is a piece of system functionality that delivers value to one or more stakeholders '''User story''' - It is a rough description of scope for future work used as planning tools. Most common format for the stories are - ''"in order to..."'',''"as a..."'',''"I want"'' '''Feature file''' - It describes a feature or a part of feature with illustrative example of expected results '''Key Example''' - Each feature is illustrated with Key Examples which show what are expected in a given test case '''Scenario''' - Scenario captures one key example for a feature file. It represents how stakeholder gets some value from that system. Example of good scenarios for checking login module includes ''user not signed up'', ''password has expired'' '''Step''' - Steps are domain language phrases which can be combined to write scenarios. They combine a GWT directive with a regular expression to evaluate something and add a simple ruby code which tells the step what should be done further.
 
==== Pattern ====
Cucumber follows a GWT (Given-When-Then) pattern for developing test cases. In the scenarios written for Cucumber, one states what a ''given'' scenario is, ''when'' one is presented with information and ''then'' what should happen so that the logic of information can be validated.

===Example===
Cucumber is a high-level testing tool that defines the feature specs. An typical [[http://www.ultrasaurus.com/sarahblog/2008/12/rails-2-day-3-behavior-driven-development/#spec example]] for a Cucumber Scenario is shown below -
First one need to install the Cucumber gem on Ruby using this simple command
<code>
$gem install cucumber-rails
Successfully installed cucumber-rails-1.0.6
1 gem installed
Installing ri documentation for cucumber-rails-1.0.6...
Installing RDoc documentation for cucumber-rails-1.0.6...
</code>
When installed, a basic Cucumber test is generated using [http://en.wikipedia.org/wiki/Generator_(computer_programming) generator] script
<code>
$script/generate rspec
$script/generate cucumber
force config/database.yml
create config/cucumber.yml
create config/environments/cucumber.rb
create script/cucumber
create features/step_definitions
create features/step_definitions/web_steps.rb
create features/support
create features/support/paths.rb
create features/support/env.rb
exists lib/tasks
create lib/tasks/cucumber.rake
</code>
A feature file is next created with name ''feature_name.featrue'' . the Feature is described in the Feature: directive, followed by the story. The story is written in the format shown in the code: ''As a <role> , I want <feature> , So that <business Value>.''
<code>
$ nano tasklist.feature 
Feature: Tasks 
In order to keep track of tasks
People should be able to
Create a list of tasks
</code>
Each feature can have multiple scenario. One such scenario for the login feature is as shown below
<code>
Scenario: List Tasks
Given that I have created a task "task 1"
When I go to the tasks page
Then I should see "task 1"
</code>
When a scenario is ready following command is issued
<code>
$script/cucumber features/tasklist.feature
0 scenarios
0 steps
</code>
Steps can be added to scenarios, which are combination of a GWT directive, a [http://en.wikipedia.org/wiki/Regular_expression regular expression] and a block of ruby code which states what this step does
<code>
/features/step_definitions$nano tasklist_steps.rb 
Given /^that I have created a task "(.*)"$/ do |desc|
Task.create!(:description => desc)
end
When /^I go to the tasks page$/ do
visit "/tasks"
end
</code>
For more elaborated examples one can refer to the [http://cukes.info/ Cucumber site].

== Other Testing Frameworks==
This sections lists more tools that are available for testing in Ruby. The frameworks and the relevant links to reading material are listed below:-

=== Riot===
Riot is a unit testing framework that results in terse tests and tries to strike a balance between Shoulda and RSpec. [http://alexyoung.org/2009/10/26/riot-testing/ Riot]

=== Capybara===
Capybara is an integration testing framework for Rack applications. [https://github.com/jnicklas/capybara Capybara]

=== Minitest ===
It is part of test::unit, but including minitest::unit has a contextual RSpec-esque syntax. [http://www.rubyinside.com/a-minitestspec-tutorial-elegant-spec-style-testing-that-comes-with-ruby-5354.html Minitest]

=== Jasmine===
Jasmine gem is a developer package used to develop Ruby web-based projects(eg. Rails, Sinatra, etc.). [https://github.com/pivotal/jasmine-gem Jasmine].

===Minispec===
Minispec is a unit testing framework. [http://flanders.co.nz/2008/05/13/using-the-mini-spec-framework-that-comes-with-ironruby/ Minispec]

= Comparison =
Now that the major frameworks have been explained briefly, here is a comparison among them based on few criteria/metrics
 
{|class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;; "cellspacing="0"; border="1"
!style="width:20%"|Metric
!style="width:20%"|Test::Unit
!style="width:20%"|Shoulda
!style="width:20%"|RSpec
!style="width:20%"|Cucumber
|-
| Framework 
| Test Driven Development framework.
| It is an extension to Test::Unit. It has more capabilities and simpler readable syntax compared to Test::Unit.
| Behavior Driven Development framework.
| Behavior Driven Development framework.
|-
| Version<ref>http://ruby-toolbox.com/categories/testing_frameworks.html</ref> 
| 1.2.3
| 2.11.3
| 2.6.0
| 1.0.6
|-

| Website 
| [http://test-unit.rubyforge.org/ Test::Unit] 
| [https://github.com/thoughtbot/shoulda Github -Shoulda] 
| [http://rspec.info/ RSpec] 
| [http://cukes.info/ Cucumber] 
|-
| Base Library <ref>http://en.wikipedia.org/wiki/Unit-testing_frameworks_for_Ruby_(programming_language)</ref> 
| Yes 
| No 
| No 
| No 
|-
| Allows nested setup <ref>http://nested-layouts.rubyforge.org/</ref>
| No 
| Yes 
| Yes 
| Yes 
|-
| Opaqueness/Expressiveness 
| Opaque to a certain extent, low level coding required 
| More descriptive 
| More expressive compared to Unit::test and shoulda. 
| More expressive compared to Unit::test and shoulda 
|-
| Run Times 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
|-
| General Use 
| Unit testing 
| Unit testing especially on the Rails framework [http://www.linuxjournal.com/magazine/forge-testing-rails-applications-shoulda] 
| Unit testing 
| Integration testing 
|}

= Conclusion =
The case as to which is the best framework, depends on scenario for which that testing framework is used. In general,[http://ruby-toolbox.com/categories/testing_frameworks.html stats] based on number of [https://github.com/ Github] views suggests, Cucumber is the industry favored testing framework for Ruby. The reason to this accounts for easy-to-use and easy-to-understand syntax and the ability to focus on only one test at a time. RSpec comes second (again in terms of [http://ruby-toolbox.com/categories/testing_frameworks.html popularity and Github views]) followed by others.

= References =
<references/>

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T19:01:50Z

Payyapp: /* Introduction to Object Oriented Design(OOD) */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T19:01:36Z

Payyapp: /* Introduction to Object Oriented Design(OOD) */

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T19:01:23Z

Payyapp:

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T18:55:58Z

Payyapp:

CSC/ECE 517 Fall 2011/ch4 5a sp

2011-10-25T18:53:37Z

Payyapp: Created page with "This page serves as a knowledge source for understanding the concepts covered in Lecture14- Introduction to Object Oriented Design(OOD)"

This page serves as a knowledge source for understanding the concepts covered in Lecture14- Introduction to Object Oriented Design(OOD)

CSC/ECE 517 Fall 2011/ch2 2e gp

2011-09-30T20:25:42Z

Payyapp: /* Riot */

='''Testing Frameworks for Ruby'''=

This page serves as a knowledge source for understanding the different Testing Frameworks available for [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]. 

__TOC__
= Introduction =
No code is perfect from the word go! Testing plays an important role in System Development Life Cycle. During testing, one follows a taxonomic procedure to uncover defects at various stages. A test framework provides various Test Types, Test Phases, Test Models, Test Metrics and acts as a guideline as to how to perform effective testing <ref> http://www.scribd.com/doc/15909730/Software-Testing-Framework </ref>. Various testing tools are available for [http://en.wikipedia.org/wiki/Ruby Ruby]language, each having some unique features over others. Here is a brief introduction and feature comparisons of popular testing frameworks.

== Testing Approaches ==
[[File:Capture5.JPG‎|thumb|right|200px|flow of test driven developmental approach]]
Before delving into testing for Ruby, in general, these are the followed approaches in industry today

=== Test Driven Development ===

This strategy, (abbreviated as TDD) <ref> http://en.wikipedia.org/wiki/Test-driven_development </ref>, though cumbersome due to its methodology develops efficient code. First a unit test is written for a function, even before the code for that function is developed. Based on this test minimal code is developed to ensure the test succeeds; if not the code is modified until test run successfully. In this iterative approach, effort is made to ensure flawless code is developed.

=== Behavior Driven Development ===
BDD <ref> http://en.wikipedia.org/wiki/Behavior_Driven_Development </ref> as its popularly know, upholds the traditional iterative workflow of Test Driven Development, but it focuses on defining behaviors that is easy to understand to naive people (with no programming background) by writing tests in natural language. This approach focuses more on looking at code development from a behavioral abstraction. For example testing the code for a recipe belonging to a category of a cookbook, in BDD would be something like 'A recipe can't be without a category'

= Unit Testing =
[http://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a method by which one can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written.
== Test::Unit ==
[[File:Capture4.JPG‎|thumb|right|400px|screen capture of TestUnit console in [http://en.wikipedia.org/wiki/RubyMine RubyMine IDE]]]

The in-built, ready to use unit testing mechanism for Ruby is called [http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit].It belongs to the XUnit family unit testing framework. It has a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests are bundled separately in a test class in the code it is aimed to test.
=== Features ===
This salient features of the Test::Unit Framework are:-
==== Assertions ====
One can use Test::Unit to make [http://en.wikipedia.org/wiki/Assertion_(computing) assertions]. The test is successful if the assertion is true and fails if the assertion is false. All the assertion methods provided by test::unit can be found at [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Test::Unit::Assertions].

{|border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

==== Test-Fixtures ====
Using a test fixture, one can initialize (and cleanup) the common set of data for two or more tests hence eliminating unnecessary duplication. Fixtures are written in the setup() and teardown() methods.
==== Test-Suite ====
As unit tests increase in number for a given project, it becomes tough running them one at a time. It is hence useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose<ref>http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/TestSuite.html</ref>.

=== Example Test ===
The Test::Unit::TestCase class is the main class and the BinarySearchTest is the subclass, it overrides setup and teardown methods. All test methods start with 'test_' prefix thus differentiating helper methods from main methods. The Test::Unit::TestCase class makes the test methods into tests, wrapping them into a suite and running the individual tests. The results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'english_french'
class EnglishFrenchTest < Test::Unit::TestCase
include EnglishFrenchTranslator
def test_simple_word
s = translate("house")
assert_equal("mason", s)
end
def test_word_beginning_with_vowel
s = translate("apple")
assert_equal("pomme", s)
end
def test_two_consonant_word
s = translate("stupid")
assert_equal("stupides", s)
end
end

The tests are run by running the file test_english_french.rb.Sample results for the above test is shown below.

$ ruby test_english_french.rb
Loaded suite test_english_french
Started
FFF
Finished in 0.01091 seconds.

3 tests, 3 assertions, 0 failures, 0 errors

== Shoulda ==
Shoulda is a library rather than a framework which gives the flexibility to write better and easy to understand tests for the Ruby application being tested. Shoulda compliments Test::Unit and RSpec in the sense that it can be used within both of them. Using Shoulda one can provide context to tests so that, tests can be grouped according to a specific feature or scenario.
===Features===

[[File:Capture1.JPG‎|thumb|left|170px|components of Shoulda]]

Shoulda consist of matchers, test-helpers and assertions<ref>http://rubydoc.info/gems/shoulda/2.11.3/frames</ref> -

'''Matchers''' 
Matchers (or more popularly simply [http://en.wikipedia.org/wiki/Macro_(computer_science)#Text_substitution_macros macros]) are Test::Unit- and RSpec-compatible one-liners that test common Rails functionality. The task of developing cumbersome, complex and often erroneous code is made simple with the help of matchers.

'''Helpers''' 
Helpers like ''#context'' and ''#should'' not only gives ''RSpec'' like test blocks in ''Test::Unit'' but also in addition to these, one gets nested contexts and a much more readable syntax.

'''Assertions''' 
Many common Rails testing idioms have been distilled into a set of useful assertions.

 

===Installation===
Shoulda for can be installed for [http://weblog.rubyonrails.org/2010/8/29/rails-3-0-it-s-done| Rails 3.0] version by including the following in the [http://gembundler.com/gemfile.html Gemfile]
<code>
group :test do
gem "shoulda"
gem "rspec-rails", "2.0.0.beta.12"
end
</code> 
===Example===

As far as usage of shoulda is concerned, one can write matchers as follows-

Suppose one is testing for the class ''Post'' on a blog, heres how it is achieved using shoulda::Macthers

<code>
class Post_Test < Test::Unit::TestCase
should belong_to(:user)
should have_many(:tags).through(:taggings) 
should validate_uniqueness_of(:title)
should validate_presence_of(:title)
should validate_numericality_of(:user_id)
end
</code>

Similarly the test for class ''Users'' can be

<code>
class Users_Test < Test::Unit::TestCase
should have_many(:posts) #checking validity of e-mail id 
should_not allow_value("blah").for(:email)
should allow_value("a@b.com").for(:email)
should_not allow_mass_assignment_of(:password)
end
</code>

As can be seen, writing test case for TDD becomes much more elegant and less error prone.

Similarly shoulda::helpers can be written as shown -

Suppose one wants to check the validity of getter method presence for an object, simply an should_have helper can be written like

<code>
context "the create action" do
setup do
@attributes = Posts.attributes_for(:item)
post :create, :item => @attributes
end 
should_create_row Item do |item|
assert_has_attributes @attributes, item #''assert_has_attributes'' - simply a helper method that makes sure the object has getter methods and values corresponding to the key/value pairs in the hash.
end
end
</code>

When this tests are run one gets the some similar following results

<code>
Loaded suite C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample
Started
...F...
Finished in 0.001000 seconds. 
1) Failure:
test: Users_Test Functions should Fail Test. (Post Test) [C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample.rb:33]:
<1> expected but was
<nil>. 
1 tests, 1 assertions, 1 failures, 0 errors, 0 skips 
Test run options: --seed 25476

</code>

The most interesting part of shoulda is the assertions which make writing test code efficient. An example of shoulda::Assertion can be seen as below

<code>
assert_same_elements([:a, :b, :c], [:c, :a, :b]) #checks whether array has same entries
assert_contains(['a', '1'], /\d/) #checks for presence of a digit
assert_contains(['a', '1'], 'a') #checks for presence of letter ''a''
</code>

== RSpec ==
[[File:Capture3.JPG‎|thumb|left|400px|flow of logic in R-Spec]]

RSpec is a Behavioral Driven development tool,created by Dave Astels and Steven Bake <ref>http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial</ref> aimed as test driven development.

RSpec is merging of two projects into one -

application level behaviour described by a Story Framework 
object level behaviour described by a Spec Framework 

The primary aim of RSpec is to drift the focus from unit testing to behavioral testing, i.e. to check if the desired functionality is achieved. It is also used to check for redundancy in code and helps refactoring our code without having to re-write every test.
===Installation===
In order to install RSpec, open a command shell, go to /bin folder in Ruby directory and type
> gem install rspec

===Features===
==== RSpec Story ====
A Story describes the functionality of a specific software feature, and it describes it in a way that is easy to understand from the point of view of a client. In fact a story can be thought of as a conversation between a client and a programmer over some feature of the software. The key points of a story are:- Title, Narrative, Scenario, Givens, Details[http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]
==== Message Expectations ====
A message expectation (a.k.a. mock method)<ref>http://rspec.info</ref> is an expectation that an object should receive a specific message during the execution of an example. This is similar to "Assertions" in test::unit.
==== Group ====
More than one executable example can be grouped into one file.
==== Spec File====
A spec file is a file that contains one or more group examples.
==== describe() and it() methods ====
The describe() method takes an arbitrary number of arguments and returns a sub-class of Spec::Example::ExampleGroup. The it() method takes a single String, an optional Hash and an optional block.

=== Example Test ===
The below code is an example for testing using rspec. The spec file, ruby file and the output are shown. It can be seen that code can be added to the spec file for different test conditions and expectations.

# archery_spec.rb
require 'archery'
describe Archery, "#score" do
it "returns 0 for all mock games" do
archery = Archery.new
20.times { archery.hit(0) }
archery.score.should == 0
end
end

# archery.rb
class Archery
def hit(arrows)
end
def score
0
end
end

$ spec archery_spec.rb --format nested
Archery#score
returns 0 for all mock games
Finished in 0.006535 seconds
1 example, 0 failures

== Cucumber ==
Cucumber is a testing tool that follows the BDD approach of testing. Cucumber written itself in Ruby programming language allows the execution of feature documentation written in natural language often termed as [http://en.wikipedia.org/wiki/User_story user stories]
=== Features of Cucumber ===

==== Terminology of Cucumber====
There are few taxonomy terms related to Cucumber <ref>http://cuke4ninja.com/sec_cucumber_jargon.html</ref> as follows-
[[File:Capture.JPG‎|thumb|left|200px|major components of Cucumber]]
'''Stakeholder''' - A person who gets some value out of the system like an administrator '''Feature''' - A feature is a piece of system functionality that delivers value to one or more stakeholders '''User story''' - It is a rough description of scope for future work used as planning tools. Most common format for the stories are - ''"in order to..."'',''"as a..."'',''"I want"'' '''Feature file''' - It describes a feature or a part of feature with illustrative example of expected results '''Key Example''' - Each feature is illustrated with Key Examples which show what are expected in a given test case '''Scenario''' - Scenario captures one key example for a feature file. It represents how stakeholder gets some value from that system. Example of good scenarios for checking login module includes ''user not signed up'', ''password has expired'' '''Step''' - Steps are domain language phrases which can be combined to write scenarios. They combine a GWT directive with a regular expression to evaluate something and add a simple ruby code which tells the step what should be done further.
 
==== Pattern ====
Cucumber follows a GWT (Given-When-Then) pattern for developing test cases. In the scenarios written for Cucumber, one states what a ''given'' scenario is, ''when'' one is presented with information and ''then'' what should happen so that the logic of information can be validated.

===Example===
Cucumber is a high-level testing tool that defines the feature specs. An typical [[http://www.ultrasaurus.com/sarahblog/2008/12/rails-2-day-3-behavior-driven-development/#spec example]] for a Cucumber Scenario is shown below -
First one need to install the Cucumber gem on Ruby using this simple command
<code>
$gem install cucumber-rails
Successfully installed cucumber-rails-1.0.6
1 gem installed
Installing ri documentation for cucumber-rails-1.0.6...
Installing RDoc documentation for cucumber-rails-1.0.6...
</code>
When installed, a basic Cucumber test is generated using [http://en.wikipedia.org/wiki/Generator_(computer_programming) generator] script
<code>
$script/generate rspec
$script/generate cucumber
force config/database.yml
create config/cucumber.yml
create config/environments/cucumber.rb
create script/cucumber
create features/step_definitions
create features/step_definitions/web_steps.rb
create features/support
create features/support/paths.rb
create features/support/env.rb
exists lib/tasks
create lib/tasks/cucumber.rake
</code>
A feature file is next created with name ''feature_name.featrue'' . the Feature is described in the Feature: directive, followed by the story. The story is written in the format shown in the code: ''As a <role> , I want <feature> , So that <business Value>.''
<code>
$ nano tasklist.feature 
Feature: Tasks 
In order to keep track of tasks
People should be able to
Create a list of tasks
</code>
Each feature can have multiple scenario. One such scenario for the login feature is as shown below
<code>
Scenario: List Tasks
Given that I have created a task "task 1"
When I go to the tasks page
Then I should see "task 1"
</code>
When a scenario is ready following command is issued
<code>
$script/cucumber features/tasklist.feature
0 scenarios
0 steps
</code>
Steps can be added to scenarios, which are combination of a GWT directive, a [http://en.wikipedia.org/wiki/Regular_expression regular expression] and a block of ruby code which states what this step does
<code>
/features/step_definitions$nano tasklist_steps.rb 
Given /^that I have created a task "(.*)"$/ do |desc|
Task.create!(:description => desc)
end
When /^I go to the tasks page$/ do
visit "/tasks"
end
</code>
For more elaborated examples one can refer to the [http://cukes.info/ Cucumber site].

== Other Testing Frameworks==
This sections lists more tools that are available for testing in Ruby. The frameworks and the relevant links to reading material are listed below:-

=== Riot===
Riot is a unit testing framework that results in terse tests and tries to strike a balance between Shoulda and RSpec. [http://alexyoung.org/2009/10/26/riot-testing/ Riot]

=== Capybara===
Capybara is an integration testing framework for Rack applications. [https://github.com/jnicklas/capybara Capybara]

=== Minitest ===
It is part of test::unit, but including minitest::unit has a contextual RSpec-esque syntax. [http://www.rubyinside.com/a-minitestspec-tutorial-elegant-spec-style-testing-that-comes-with-ruby-5354.html Minitest]

=== Jasmine===
Jasmine gem is a developer package used to develop Ruby web-based projects(eg. Rails, Sinatra, etc.). [https://github.com/pivotal/jasmine-gem Jasmine].

===Minispec===
Minispec is a unit testing framework. [http://flanders.co.nz/2008/05/13/using-the-mini-spec-framework-that-comes-with-ironruby/ Minispec]

= Comparison =
Now that the major frameworks have been explained briefly, here is a comparison among them based on few criteria/metrics
 
{|class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;; "cellspacing="0"; border="1"
!style="width:20%"|Metric
!style="width:20%"|Test::Unit
!style="width:20%"|Shoulda
!style="width:20%"|RSpec
!style="width:20%"|Cucumber
|-
| Framework 
| Test Driven Development framework.
| It is an extension to Test::Unit. It has more capabilities and simpler readable syntax compared to Test::Unit.
| Behavior Driven Development framework.
| Behavior Driven Development framework.
|-
| Version<ref>http://ruby-toolbox.com/categories/testing_frameworks.html</ref> 
| 1.2.3
| 2.11.3
| 2.6.0
| 1.0.6
|-

| Website 
| [http://test-unit.rubyforge.org/ Test::Unit] 
| [https://github.com/thoughtbot/shoulda Github -Shoulda] 
| [http://rspec.info/ RSpec] 
| [http://cukes.info/ Cucumber] 
|-
| Base Library <ref>http://en.wikipedia.org/wiki/Unit-testing_frameworks_for_Ruby_(programming_language)</ref> 
| Yes 
| No 
| No 
| No 
|-
| Allows nested setup <ref>http://nested-layouts.rubyforge.org/</ref>
| No 
| Yes 
| Yes 
| Yes 
|-
| Opaqueness/Expressiveness 
| Opaque to a certain extent, low level coding required 
| More descriptive 
| More expressive compared to Unit::test and shoulda. 
| More expressive compared to Unit::test and shoulda 
|-
| Run Times 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
|-
| General Use 
| Unit testing 
| Unit testing especially on the Rails framework [http://www.linuxjournal.com/magazine/forge-testing-rails-applications-shoulda] 
| Unit testing 
| Integration testing 
|}

= Conclusion =
The case as to which is the best framework, depends on scenario for which that testing framework is used. In general,[http://ruby-toolbox.com/categories/testing_frameworks.html stats] based on number of [https://github.com/ Github] views suggests, Cucumber is the industry favored testing framework for Ruby. The reason to this accounts for easy-to-use and easy-to-understand syntax and the ability to focus on only one test at a time. RSpec comes second (again in terms of [http://ruby-toolbox.com/categories/testing_frameworks.html popularity and Github views]) followed by others.

= References =
<references/>

CSC/ECE 517 Fall 2011/ch2 2e gp

2011-09-30T20:18:32Z

Payyapp: /* Riot */

='''Testing Frameworks for Ruby'''=

This page serves as a knowledge source for understanding the different Testing Frameworks available for [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]. 

__TOC__
= Introduction =
No code is perfect from the word go! Testing plays an important role in System Development Life Cycle. During testing, one follows a taxonomic procedure to uncover defects at various stages. A test framework provides various Test Types, Test Phases, Test Models, Test Metrics and acts as a guideline as to how to perform effective testing <ref> http://www.scribd.com/doc/15909730/Software-Testing-Framework </ref>. Various testing tools are available for [http://en.wikipedia.org/wiki/Ruby Ruby]language, each having some unique features over others. Here is a brief introduction and feature comparisons of popular testing frameworks.

== Testing Approaches ==
[[File:Capture5.JPG‎|thumb|right|200px|flow of test driven developmental approach]]
Before delving into testing for Ruby, in general, these are the followed approaches in industry today

=== Test Driven Development ===

This strategy, (abbreviated as TDD) <ref> http://en.wikipedia.org/wiki/Test-driven_development </ref>, though cumbersome due to its methodology develops efficient code. First a unit test is written for a function, even before the code for that function is developed. Based on this test minimal code is developed to ensure the test succeeds; if not the code is modified until test run successfully. In this iterative approach, effort is made to ensure flawless code is developed.

=== Behavior Driven Development ===
BDD <ref> http://en.wikipedia.org/wiki/Behavior_Driven_Development </ref> as its popularly know, upholds the traditional iterative workflow of Test Driven Development, but it focuses on defining behaviors that is easy to understand to naive people (with no programming background) by writing tests in natural language. This approach focuses more on looking at code development from a behavioral abstraction. For example testing the code for a recipe belonging to a category of a cookbook, in BDD would be something like 'A recipe can't be without a category'

= Unit Testing =
[http://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a method by which one can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written.
== Test::Unit ==
[[File:Capture4.JPG‎|thumb|right|400px|screen capture of TestUnit console in [http://en.wikipedia.org/wiki/RubyMine RubyMine IDE]]]

The in-built, ready to use unit testing mechanism for Ruby is called [http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit].It belongs to the XUnit family unit testing framework. It has a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests are bundled separately in a test class in the code it is aimed to test.
=== Features ===
This salient features of the Test::Unit Framework are:-
==== Assertions ====
One can use Test::Unit to make [http://en.wikipedia.org/wiki/Assertion_(computing) assertions]. The test is successful if the assertion is true and fails if the assertion is false. All the assertion methods provided by test::unit can be found at [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Test::Unit::Assertions].

{|border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

==== Test-Fixtures ====
Using a test fixture, one can initialize (and cleanup) the common set of data for two or more tests hence eliminating unnecessary duplication. Fixtures are written in the setup() and teardown() methods.
==== Test-Suite ====
As unit tests increase in number for a given project, it becomes tough running them one at a time. It is hence useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose<ref>http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/TestSuite.html</ref>.

=== Example Test ===
The Test::Unit::TestCase class is the main class and the BinarySearchTest is the subclass, it overrides setup and teardown methods. All test methods start with 'test_' prefix thus differentiating helper methods from main methods. The Test::Unit::TestCase class makes the test methods into tests, wrapping them into a suite and running the individual tests. The results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'english_french'
class EnglishFrenchTest < Test::Unit::TestCase
include EnglishFrenchTranslator
def test_simple_word
s = translate("house")
assert_equal("mason", s)
end
def test_word_beginning_with_vowel
s = translate("apple")
assert_equal("pomme", s)
end
def test_two_consonant_word
s = translate("stupid")
assert_equal("stupides", s)
end
end

The tests are run by running the file test_english_french.rb.Sample results for the above test is shown below.

$ ruby test_english_french.rb
Loaded suite test_english_french
Started
FFF
Finished in 0.01091 seconds.

3 tests, 3 assertions, 0 failures, 0 errors

== Shoulda ==
Shoulda is a library rather than a framework which gives the flexibility to write better and easy to understand tests for the Ruby application being tested. Shoulda compliments Test::Unit and RSpec in the sense that it can be used within both of them. Using Shoulda one can provide context to tests so that, tests can be grouped according to a specific feature or scenario.
===Features===

[[File:Capture1.JPG‎|thumb|left|170px|components of Shoulda]]

Shoulda consist of matchers, test-helpers and assertions<ref>http://rubydoc.info/gems/shoulda/2.11.3/frames</ref> -

'''Matchers''' 
Matchers (or more popularly simply [http://en.wikipedia.org/wiki/Macro_(computer_science)#Text_substitution_macros macros]) are Test::Unit- and RSpec-compatible one-liners that test common Rails functionality. The task of developing cumbersome, complex and often erroneous code is made simple with the help of matchers.

'''Helpers''' 
Helpers like ''#context'' and ''#should'' not only gives ''RSpec'' like test blocks in ''Test::Unit'' but also in addition to these, one gets nested contexts and a much more readable syntax.

'''Assertions''' 
Many common Rails testing idioms have been distilled into a set of useful assertions.

 

===Installation===
Shoulda for can be installed for [http://weblog.rubyonrails.org/2010/8/29/rails-3-0-it-s-done| Rails 3.0] version by including the following in the [http://gembundler.com/gemfile.html Gemfile]
<code>
group :test do
gem "shoulda"
gem "rspec-rails", "2.0.0.beta.12"
end
</code> 
===Example===

As far as usage of shoulda is concerned, one can write matchers as follows-

Suppose one is testing for the class ''Post'' on a blog, heres how it is achieved using shoulda::Macthers

<code>
class Post_Test < Test::Unit::TestCase
should belong_to(:user)
should have_many(:tags).through(:taggings) 
should validate_uniqueness_of(:title)
should validate_presence_of(:title)
should validate_numericality_of(:user_id)
end
</code>

Similarly the test for class ''Users'' can be

<code>
class Users_Test < Test::Unit::TestCase
should have_many(:posts) #checking validity of e-mail id 
should_not allow_value("blah").for(:email)
should allow_value("a@b.com").for(:email)
should_not allow_mass_assignment_of(:password)
end
</code>

As can be seen, writing test case for TDD becomes much more elegant and less error prone.

Similarly shoulda::helpers can be written as shown -

Suppose one wants to check the validity of getter method presence for an object, simply an should_have helper can be written like

<code>
context "the create action" do
setup do
@attributes = Posts.attributes_for(:item)
post :create, :item => @attributes
end 
should_create_row Item do |item|
assert_has_attributes @attributes, item #''assert_has_attributes'' - simply a helper method that makes sure the object has getter methods and values corresponding to the key/value pairs in the hash.
end
end
</code>

When this tests are run one gets the some similar following results

<code>
Loaded suite C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample
Started
...F...
Finished in 0.001000 seconds. 
1) Failure:
test: Users_Test Functions should Fail Test. (Post Test) [C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample.rb:33]:
<1> expected but was
<nil>. 
1 tests, 1 assertions, 1 failures, 0 errors, 0 skips 
Test run options: --seed 25476

</code>

The most interesting part of shoulda is the assertions which make writing test code efficient. An example of shoulda::Assertion can be seen as below

<code>
assert_same_elements([:a, :b, :c], [:c, :a, :b]) #checks whether array has same entries
assert_contains(['a', '1'], /\d/) #checks for presence of a digit
assert_contains(['a', '1'], 'a') #checks for presence of letter ''a''
</code>

== RSpec ==
[[File:Capture3.JPG‎|thumb|left|400px|flow of logic in R-Spec]]

RSpec is a Behavioral Driven development tool,created by Dave Astels and Steven Bake <ref>http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial</ref> aimed as test driven development.

RSpec is merging of two projects into one -

application level behaviour described by a Story Framework 
object level behaviour described by a Spec Framework 

The primary aim of RSpec is to drift the focus from unit testing to behavioral testing, i.e. to check if the desired functionality is achieved. It is also used to check for redundancy in code and helps refactoring our code without having to re-write every test.
===Installation===
In order to install RSpec, open a command shell, go to /bin folder in Ruby directory and type
> gem install rspec

===Features===
==== RSpec Story ====
A Story describes the functionality of a specific software feature, and it describes it in a way that is easy to understand from the point of view of a client. In fact a story can be thought of as a conversation between a client and a programmer over some feature of the software. The key points of a story are:- Title, Narrative, Scenario, Givens, Details[http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]
==== Message Expectations ====
A message expectation (a.k.a. mock method)<ref>http://rspec.info</ref> is an expectation that an object should receive a specific message during the execution of an example. This is similar to "Assertions" in test::unit.
==== Group ====
More than one executable example can be grouped into one file.
==== Spec File====
A spec file is a file that contains one or more group examples.
==== describe() and it() methods ====
The describe() method takes an arbitrary number of arguments and returns a sub-class of Spec::Example::ExampleGroup. The it() method takes a single String, an optional Hash and an optional block.

=== Example Test ===
The below code is an example for testing using rspec. The spec file, ruby file and the output are shown. It can be seen that code can be added to the spec file for different test conditions and expectations.

# archery_spec.rb
require 'archery'
describe Archery, "#score" do
it "returns 0 for all mock games" do
archery = Archery.new
20.times { archery.hit(0) }
archery.score.should == 0
end
end

# archery.rb
class Archery
def hit(arrows)
end
def score
0
end
end

$ spec archery_spec.rb --format nested
Archery#score
returns 0 for all mock games
Finished in 0.006535 seconds
1 example, 0 failures

== Cucumber ==
Cucumber is a testing tool that follows the BDD approach of testing. Cucumber written itself in Ruby programming language allows the execution of feature documentation written in natural language often termed as [http://en.wikipedia.org/wiki/User_story user stories]
=== Features of Cucumber ===

==== Terminology of Cucumber====
There are few taxonomy terms related to Cucumber <ref>http://cuke4ninja.com/sec_cucumber_jargon.html</ref> as follows-
[[File:Capture.JPG‎|thumb|left|200px|major components of Cucumber]]
'''Stakeholder''' - A person who gets some value out of the system like an administrator '''Feature''' - A feature is a piece of system functionality that delivers value to one or more stakeholders '''User story''' - It is a rough description of scope for future work used as planning tools. Most common format for the stories are - ''"in order to..."'',''"as a..."'',''"I want"'' '''Feature file''' - It describes a feature or a part of feature with illustrative example of expected results '''Key Example''' - Each feature is illustrated with Key Examples which show what are expected in a given test case '''Scenario''' - Scenario captures one key example for a feature file. It represents how stakeholder gets some value from that system. Example of good scenarios for checking login module includes ''user not signed up'', ''password has expired'' '''Step''' - Steps are domain language phrases which can be combined to write scenarios. They combine a GWT directive with a regular expression to evaluate something and add a simple ruby code which tells the step what should be done further.
 
==== Pattern ====
Cucumber follows a GWT (Given-When-Then) pattern for developing test cases. In the scenarios written for Cucumber, one states what a ''given'' scenario is, ''when'' one is presented with information and ''then'' what should happen so that the logic of information can be validated.

===Example===
Cucumber is a high-level testing tool that defines the feature specs. An typical [[http://www.ultrasaurus.com/sarahblog/2008/12/rails-2-day-3-behavior-driven-development/#spec example]] for a Cucumber Scenario is shown below -
First one need to install the Cucumber gem on Ruby using this simple command
<code>
$gem install cucumber-rails
Successfully installed cucumber-rails-1.0.6
1 gem installed
Installing ri documentation for cucumber-rails-1.0.6...
Installing RDoc documentation for cucumber-rails-1.0.6...
</code>
When installed, a basic Cucumber test is generated using [http://en.wikipedia.org/wiki/Generator_(computer_programming) generator] script
<code>
$script/generate rspec
$script/generate cucumber
force config/database.yml
create config/cucumber.yml
create config/environments/cucumber.rb
create script/cucumber
create features/step_definitions
create features/step_definitions/web_steps.rb
create features/support
create features/support/paths.rb
create features/support/env.rb
exists lib/tasks
create lib/tasks/cucumber.rake
</code>
A feature file is next created with name ''feature_name.featrue'' . the Feature is described in the Feature: directive, followed by the story. The story is written in the format shown in the code: ''As a <role> , I want <feature> , So that <business Value>.''
<code>
$ nano tasklist.feature 
Feature: Tasks 
In order to keep track of tasks
People should be able to
Create a list of tasks
</code>
Each feature can have multiple scenario. One such scenario for the login feature is as shown below
<code>
Scenario: List Tasks
Given that I have created a task "task 1"
When I go to the tasks page
Then I should see "task 1"
</code>
When a scenario is ready following command is issued
<code>
$script/cucumber features/tasklist.feature
0 scenarios
0 steps
</code>
Steps can be added to scenarios, which are combination of a GWT directive, a [http://en.wikipedia.org/wiki/Regular_expression regular expression] and a block of ruby code which states what this step does
<code>
/features/step_definitions$nano tasklist_steps.rb 
Given /^that I have created a task "(.*)"$/ do |desc|
Task.create!(:description => desc)
end
When /^I go to the tasks page$/ do
visit "/tasks"
end
</code>
For more elaborated examples one can refer to the [http://cukes.info/ Cucumber site].

== Other Testing Frameworks==
This sections lists more tools that are available for testing in Ruby. The frameworks and the relevant links to reading material are listed below:-

=== Riot===
Riot is a unit testing framework that results in terse tests and tries to strike a balance between Shoulda and RSpec. [http://alexyoung.org/2009/10/26/riot-testing/ Riot]

= Comparison =
Now that the major frameworks have been explained briefly, here is a comparison among them based on few criteria/metrics
 
{|class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;; "cellspacing="0"; border="1"
!style="width:20%"|Metric
!style="width:20%"|Test::Unit
!style="width:20%"|Shoulda
!style="width:20%"|RSpec
!style="width:20%"|Cucumber
|-
| Framework 
| Test Driven Development framework.
| It is an extension to Test::Unit. It has more capabilities and simpler readable syntax compared to Test::Unit.
| Behavior Driven Development framework.
| Behavior Driven Development framework.
|-
| Version<ref>http://ruby-toolbox.com/categories/testing_frameworks.html</ref> 
| 1.2.3
| 2.11.3
| 2.6.0
| 1.0.6
|-

| Website 
| [http://test-unit.rubyforge.org/ Test::Unit] 
| [https://github.com/thoughtbot/shoulda Github -Shoulda] 
| [http://rspec.info/ RSpec] 
| [http://cukes.info/ Cucumber] 
|-
| Base Library <ref>http://en.wikipedia.org/wiki/Unit-testing_frameworks_for_Ruby_(programming_language)</ref> 
| Yes 
| No 
| No 
| No 
|-
| Allows nested setup <ref>http://nested-layouts.rubyforge.org/</ref>
| No 
| Yes 
| Yes 
| Yes 
|-
| Opaqueness/Expressiveness 
| Opaque to a certain extent, low level coding required 
| More descriptive 
| More expressive compared to Unit::test and shoulda. 
| More expressive compared to Unit::test and shoulda 
|-
| Run Times 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
|-
| General Use 
| Unit testing 
| Unit testing especially on the Rails framework [http://www.linuxjournal.com/magazine/forge-testing-rails-applications-shoulda] 
| Unit testing 
| Integration testing 
|}

= Conclusion =
The case as to which is the best framework, depends on scenario for which that testing framework is used. In general,[http://ruby-toolbox.com/categories/testing_frameworks.html stats] based on number of [https://github.com/ Github] views suggests, Cucumber is the industry favored testing framework for Ruby. The reason to this accounts for easy-to-use and easy-to-understand syntax and the ability to focus on only one test at a time. RSpec comes second (again in terms of [http://ruby-toolbox.com/categories/testing_frameworks.html popularity and Github views]) followed by others.

= References =
<references/>

CSC/ECE 517 Fall 2011/ch2 2e gp

2011-09-30T20:18:22Z

Payyapp: /* Other Testing Frameworks */

='''Testing Frameworks for Ruby'''=

This page serves as a knowledge source for understanding the different Testing Frameworks available for [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]. 

__TOC__
= Introduction =
No code is perfect from the word go! Testing plays an important role in System Development Life Cycle. During testing, one follows a taxonomic procedure to uncover defects at various stages. A test framework provides various Test Types, Test Phases, Test Models, Test Metrics and acts as a guideline as to how to perform effective testing <ref> http://www.scribd.com/doc/15909730/Software-Testing-Framework </ref>. Various testing tools are available for [http://en.wikipedia.org/wiki/Ruby Ruby]language, each having some unique features over others. Here is a brief introduction and feature comparisons of popular testing frameworks.

== Testing Approaches ==
[[File:Capture5.JPG‎|thumb|right|200px|flow of test driven developmental approach]]
Before delving into testing for Ruby, in general, these are the followed approaches in industry today

=== Test Driven Development ===

This strategy, (abbreviated as TDD) <ref> http://en.wikipedia.org/wiki/Test-driven_development </ref>, though cumbersome due to its methodology develops efficient code. First a unit test is written for a function, even before the code for that function is developed. Based on this test minimal code is developed to ensure the test succeeds; if not the code is modified until test run successfully. In this iterative approach, effort is made to ensure flawless code is developed.

=== Behavior Driven Development ===
BDD <ref> http://en.wikipedia.org/wiki/Behavior_Driven_Development </ref> as its popularly know, upholds the traditional iterative workflow of Test Driven Development, but it focuses on defining behaviors that is easy to understand to naive people (with no programming background) by writing tests in natural language. This approach focuses more on looking at code development from a behavioral abstraction. For example testing the code for a recipe belonging to a category of a cookbook, in BDD would be something like 'A recipe can't be without a category'

= Unit Testing =
[http://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a method by which one can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written.
== Test::Unit ==
[[File:Capture4.JPG‎|thumb|right|400px|screen capture of TestUnit console in [http://en.wikipedia.org/wiki/RubyMine RubyMine IDE]]]

The in-built, ready to use unit testing mechanism for Ruby is called [http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit].It belongs to the XUnit family unit testing framework. It has a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests are bundled separately in a test class in the code it is aimed to test.
=== Features ===
This salient features of the Test::Unit Framework are:-
==== Assertions ====
One can use Test::Unit to make [http://en.wikipedia.org/wiki/Assertion_(computing) assertions]. The test is successful if the assertion is true and fails if the assertion is false. All the assertion methods provided by test::unit can be found at [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Test::Unit::Assertions].

{|border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

==== Test-Fixtures ====
Using a test fixture, one can initialize (and cleanup) the common set of data for two or more tests hence eliminating unnecessary duplication. Fixtures are written in the setup() and teardown() methods.
==== Test-Suite ====
As unit tests increase in number for a given project, it becomes tough running them one at a time. It is hence useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose<ref>http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/TestSuite.html</ref>.

=== Example Test ===
The Test::Unit::TestCase class is the main class and the BinarySearchTest is the subclass, it overrides setup and teardown methods. All test methods start with 'test_' prefix thus differentiating helper methods from main methods. The Test::Unit::TestCase class makes the test methods into tests, wrapping them into a suite and running the individual tests. The results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'english_french'
class EnglishFrenchTest < Test::Unit::TestCase
include EnglishFrenchTranslator
def test_simple_word
s = translate("house")
assert_equal("mason", s)
end
def test_word_beginning_with_vowel
s = translate("apple")
assert_equal("pomme", s)
end
def test_two_consonant_word
s = translate("stupid")
assert_equal("stupides", s)
end
end

The tests are run by running the file test_english_french.rb.Sample results for the above test is shown below.

$ ruby test_english_french.rb
Loaded suite test_english_french
Started
FFF
Finished in 0.01091 seconds.

3 tests, 3 assertions, 0 failures, 0 errors

== Shoulda ==
Shoulda is a library rather than a framework which gives the flexibility to write better and easy to understand tests for the Ruby application being tested. Shoulda compliments Test::Unit and RSpec in the sense that it can be used within both of them. Using Shoulda one can provide context to tests so that, tests can be grouped according to a specific feature or scenario.
===Features===

[[File:Capture1.JPG‎|thumb|left|170px|components of Shoulda]]

Shoulda consist of matchers, test-helpers and assertions<ref>http://rubydoc.info/gems/shoulda/2.11.3/frames</ref> -

'''Matchers''' 
Matchers (or more popularly simply [http://en.wikipedia.org/wiki/Macro_(computer_science)#Text_substitution_macros macros]) are Test::Unit- and RSpec-compatible one-liners that test common Rails functionality. The task of developing cumbersome, complex and often erroneous code is made simple with the help of matchers.

'''Helpers''' 
Helpers like ''#context'' and ''#should'' not only gives ''RSpec'' like test blocks in ''Test::Unit'' but also in addition to these, one gets nested contexts and a much more readable syntax.

'''Assertions''' 
Many common Rails testing idioms have been distilled into a set of useful assertions.

 

===Installation===
Shoulda for can be installed for [http://weblog.rubyonrails.org/2010/8/29/rails-3-0-it-s-done| Rails 3.0] version by including the following in the [http://gembundler.com/gemfile.html Gemfile]
<code>
group :test do
gem "shoulda"
gem "rspec-rails", "2.0.0.beta.12"
end
</code> 
===Example===

As far as usage of shoulda is concerned, one can write matchers as follows-

Suppose one is testing for the class ''Post'' on a blog, heres how it is achieved using shoulda::Macthers

<code>
class Post_Test < Test::Unit::TestCase
should belong_to(:user)
should have_many(:tags).through(:taggings) 
should validate_uniqueness_of(:title)
should validate_presence_of(:title)
should validate_numericality_of(:user_id)
end
</code>

Similarly the test for class ''Users'' can be

<code>
class Users_Test < Test::Unit::TestCase
should have_many(:posts) #checking validity of e-mail id 
should_not allow_value("blah").for(:email)
should allow_value("a@b.com").for(:email)
should_not allow_mass_assignment_of(:password)
end
</code>

As can be seen, writing test case for TDD becomes much more elegant and less error prone.

Similarly shoulda::helpers can be written as shown -

Suppose one wants to check the validity of getter method presence for an object, simply an should_have helper can be written like

<code>
context "the create action" do
setup do
@attributes = Posts.attributes_for(:item)
post :create, :item => @attributes
end 
should_create_row Item do |item|
assert_has_attributes @attributes, item #''assert_has_attributes'' - simply a helper method that makes sure the object has getter methods and values corresponding to the key/value pairs in the hash.
end
end
</code>

When this tests are run one gets the some similar following results

<code>
Loaded suite C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample
Started
...F...
Finished in 0.001000 seconds. 
1) Failure:
test: Users_Test Functions should Fail Test. (Post Test) [C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample.rb:33]:
<1> expected but was
<nil>. 
1 tests, 1 assertions, 1 failures, 0 errors, 0 skips 
Test run options: --seed 25476

</code>

The most interesting part of shoulda is the assertions which make writing test code efficient. An example of shoulda::Assertion can be seen as below

<code>
assert_same_elements([:a, :b, :c], [:c, :a, :b]) #checks whether array has same entries
assert_contains(['a', '1'], /\d/) #checks for presence of a digit
assert_contains(['a', '1'], 'a') #checks for presence of letter ''a''
</code>

== RSpec ==
[[File:Capture3.JPG‎|thumb|left|400px|flow of logic in R-Spec]]

RSpec is a Behavioral Driven development tool,created by Dave Astels and Steven Bake <ref>http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial</ref> aimed as test driven development.

RSpec is merging of two projects into one -

application level behaviour described by a Story Framework 
object level behaviour described by a Spec Framework 

The primary aim of RSpec is to drift the focus from unit testing to behavioral testing, i.e. to check if the desired functionality is achieved. It is also used to check for redundancy in code and helps refactoring our code without having to re-write every test.
===Installation===
In order to install RSpec, open a command shell, go to /bin folder in Ruby directory and type
> gem install rspec

===Features===
==== RSpec Story ====
A Story describes the functionality of a specific software feature, and it describes it in a way that is easy to understand from the point of view of a client. In fact a story can be thought of as a conversation between a client and a programmer over some feature of the software. The key points of a story are:- Title, Narrative, Scenario, Givens, Details[http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]
==== Message Expectations ====
A message expectation (a.k.a. mock method)<ref>http://rspec.info</ref> is an expectation that an object should receive a specific message during the execution of an example. This is similar to "Assertions" in test::unit.
==== Group ====
More than one executable example can be grouped into one file.
==== Spec File====
A spec file is a file that contains one or more group examples.
==== describe() and it() methods ====
The describe() method takes an arbitrary number of arguments and returns a sub-class of Spec::Example::ExampleGroup. The it() method takes a single String, an optional Hash and an optional block.

=== Example Test ===
The below code is an example for testing using rspec. The spec file, ruby file and the output are shown. It can be seen that code can be added to the spec file for different test conditions and expectations.

# archery_spec.rb
require 'archery'
describe Archery, "#score" do
it "returns 0 for all mock games" do
archery = Archery.new
20.times { archery.hit(0) }
archery.score.should == 0
end
end

# archery.rb
class Archery
def hit(arrows)
end
def score
0
end
end

$ spec archery_spec.rb --format nested
Archery#score
returns 0 for all mock games
Finished in 0.006535 seconds
1 example, 0 failures

== Cucumber ==
Cucumber is a testing tool that follows the BDD approach of testing. Cucumber written itself in Ruby programming language allows the execution of feature documentation written in natural language often termed as [http://en.wikipedia.org/wiki/User_story user stories]
=== Features of Cucumber ===

==== Terminology of Cucumber====
There are few taxonomy terms related to Cucumber <ref>http://cuke4ninja.com/sec_cucumber_jargon.html</ref> as follows-
[[File:Capture.JPG‎|thumb|left|200px|major components of Cucumber]]
'''Stakeholder''' - A person who gets some value out of the system like an administrator '''Feature''' - A feature is a piece of system functionality that delivers value to one or more stakeholders '''User story''' - It is a rough description of scope for future work used as planning tools. Most common format for the stories are - ''"in order to..."'',''"as a..."'',''"I want"'' '''Feature file''' - It describes a feature or a part of feature with illustrative example of expected results '''Key Example''' - Each feature is illustrated with Key Examples which show what are expected in a given test case '''Scenario''' - Scenario captures one key example for a feature file. It represents how stakeholder gets some value from that system. Example of good scenarios for checking login module includes ''user not signed up'', ''password has expired'' '''Step''' - Steps are domain language phrases which can be combined to write scenarios. They combine a GWT directive with a regular expression to evaluate something and add a simple ruby code which tells the step what should be done further.
 
==== Pattern ====
Cucumber follows a GWT (Given-When-Then) pattern for developing test cases. In the scenarios written for Cucumber, one states what a ''given'' scenario is, ''when'' one is presented with information and ''then'' what should happen so that the logic of information can be validated.

===Example===
Cucumber is a high-level testing tool that defines the feature specs. An typical [[http://www.ultrasaurus.com/sarahblog/2008/12/rails-2-day-3-behavior-driven-development/#spec example]] for a Cucumber Scenario is shown below -
First one need to install the Cucumber gem on Ruby using this simple command
<code>
$gem install cucumber-rails
Successfully installed cucumber-rails-1.0.6
1 gem installed
Installing ri documentation for cucumber-rails-1.0.6...
Installing RDoc documentation for cucumber-rails-1.0.6...
</code>
When installed, a basic Cucumber test is generated using [http://en.wikipedia.org/wiki/Generator_(computer_programming) generator] script
<code>
$script/generate rspec
$script/generate cucumber
force config/database.yml
create config/cucumber.yml
create config/environments/cucumber.rb
create script/cucumber
create features/step_definitions
create features/step_definitions/web_steps.rb
create features/support
create features/support/paths.rb
create features/support/env.rb
exists lib/tasks
create lib/tasks/cucumber.rake
</code>
A feature file is next created with name ''feature_name.featrue'' . the Feature is described in the Feature: directive, followed by the story. The story is written in the format shown in the code: ''As a <role> , I want <feature> , So that <business Value>.''
<code>
$ nano tasklist.feature 
Feature: Tasks 
In order to keep track of tasks
People should be able to
Create a list of tasks
</code>
Each feature can have multiple scenario. One such scenario for the login feature is as shown below
<code>
Scenario: List Tasks
Given that I have created a task "task 1"
When I go to the tasks page
Then I should see "task 1"
</code>
When a scenario is ready following command is issued
<code>
$script/cucumber features/tasklist.feature
0 scenarios
0 steps
</code>
Steps can be added to scenarios, which are combination of a GWT directive, a [http://en.wikipedia.org/wiki/Regular_expression regular expression] and a block of ruby code which states what this step does
<code>
/features/step_definitions$nano tasklist_steps.rb 
Given /^that I have created a task "(.*)"$/ do |desc|
Task.create!(:description => desc)
end
When /^I go to the tasks page$/ do
visit "/tasks"
end
</code>
For more elaborated examples one can refer to the [http://cukes.info/ Cucumber site].

== Other Testing Frameworks==
This sections lists more tools that are available for testing in Ruby. The frameworks and the relevant links to reading material are listed below:-

=== Riot===
Riot is a unit testing framework that results in terse tests and tries to strike a balance between Shoulda and RSpec. [http:http://alexyoung.org/2009/10/26/riot-testing/ Riot]

= Comparison =
Now that the major frameworks have been explained briefly, here is a comparison among them based on few criteria/metrics
 
{|class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;; "cellspacing="0"; border="1"
!style="width:20%"|Metric
!style="width:20%"|Test::Unit
!style="width:20%"|Shoulda
!style="width:20%"|RSpec
!style="width:20%"|Cucumber
|-
| Framework 
| Test Driven Development framework.
| It is an extension to Test::Unit. It has more capabilities and simpler readable syntax compared to Test::Unit.
| Behavior Driven Development framework.
| Behavior Driven Development framework.
|-
| Version<ref>http://ruby-toolbox.com/categories/testing_frameworks.html</ref> 
| 1.2.3
| 2.11.3
| 2.6.0
| 1.0.6
|-

| Website 
| [http://test-unit.rubyforge.org/ Test::Unit] 
| [https://github.com/thoughtbot/shoulda Github -Shoulda] 
| [http://rspec.info/ RSpec] 
| [http://cukes.info/ Cucumber] 
|-
| Base Library <ref>http://en.wikipedia.org/wiki/Unit-testing_frameworks_for_Ruby_(programming_language)</ref> 
| Yes 
| No 
| No 
| No 
|-
| Allows nested setup <ref>http://nested-layouts.rubyforge.org/</ref>
| No 
| Yes 
| Yes 
| Yes 
|-
| Opaqueness/Expressiveness 
| Opaque to a certain extent, low level coding required 
| More descriptive 
| More expressive compared to Unit::test and shoulda. 
| More expressive compared to Unit::test and shoulda 
|-
| Run Times 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
|-
| General Use 
| Unit testing 
| Unit testing especially on the Rails framework [http://www.linuxjournal.com/magazine/forge-testing-rails-applications-shoulda] 
| Unit testing 
| Integration testing 
|}

= Conclusion =
The case as to which is the best framework, depends on scenario for which that testing framework is used. In general,[http://ruby-toolbox.com/categories/testing_frameworks.html stats] based on number of [https://github.com/ Github] views suggests, Cucumber is the industry favored testing framework for Ruby. The reason to this accounts for easy-to-use and easy-to-understand syntax and the ability to focus on only one test at a time. RSpec comes second (again in terms of [http://ruby-toolbox.com/categories/testing_frameworks.html popularity and Github views]) followed by others.

= References =
<references/>

CSC/ECE 517 Fall 2011/ch2 2e gp

2011-09-30T20:12:05Z

Payyapp:

='''Testing Frameworks for Ruby'''=

This page serves as a knowledge source for understanding the different Testing Frameworks available for [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]. 

__TOC__
= Introduction =
No code is perfect from the word go! Testing plays an important role in System Development Life Cycle. During testing, one follows a taxonomic procedure to uncover defects at various stages. A test framework provides various Test Types, Test Phases, Test Models, Test Metrics and acts as a guideline as to how to perform effective testing <ref> http://www.scribd.com/doc/15909730/Software-Testing-Framework </ref>. Various testing tools are available for [http://en.wikipedia.org/wiki/Ruby Ruby]language, each having some unique features over others. Here is a brief introduction and feature comparisons of popular testing frameworks.

== Testing Approaches ==
[[File:Capture5.JPG‎|thumb|right|200px|flow of test driven developmental approach]]
Before delving into testing for Ruby, in general, these are the followed approaches in industry today

=== Test Driven Development ===

This strategy, (abbreviated as TDD) <ref> http://en.wikipedia.org/wiki/Test-driven_development </ref>, though cumbersome due to its methodology develops efficient code. First a unit test is written for a function, even before the code for that function is developed. Based on this test minimal code is developed to ensure the test succeeds; if not the code is modified until test run successfully. In this iterative approach, effort is made to ensure flawless code is developed.

=== Behavior Driven Development ===
BDD <ref> http://en.wikipedia.org/wiki/Behavior_Driven_Development </ref> as its popularly know, upholds the traditional iterative workflow of Test Driven Development, but it focuses on defining behaviors that is easy to understand to naive people (with no programming background) by writing tests in natural language. This approach focuses more on looking at code development from a behavioral abstraction. For example testing the code for a recipe belonging to a category of a cookbook, in BDD would be something like 'A recipe can't be without a category'

= Unit Testing =
[http://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a method by which one can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written.
== Test::Unit ==
[[File:Capture4.JPG‎|thumb|right|400px|screen capture of TestUnit console in [http://en.wikipedia.org/wiki/RubyMine RubyMine IDE]]]

The in-built, ready to use unit testing mechanism for Ruby is called [http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit].It belongs to the XUnit family unit testing framework. It has a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests are bundled separately in a test class in the code it is aimed to test.
=== Features ===
This salient features of the Test::Unit Framework are:-
==== Assertions ====
One can use Test::Unit to make [http://en.wikipedia.org/wiki/Assertion_(computing) assertions]. The test is successful if the assertion is true and fails if the assertion is false. All the assertion methods provided by test::unit can be found at [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Test::Unit::Assertions].

{|border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

==== Test-Fixtures ====
Using a test fixture, one can initialize (and cleanup) the common set of data for two or more tests hence eliminating unnecessary duplication. Fixtures are written in the setup() and teardown() methods.
==== Test-Suite ====
As unit tests increase in number for a given project, it becomes tough running them one at a time. It is hence useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose<ref>http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/TestSuite.html</ref>.

=== Example Test ===
The Test::Unit::TestCase class is the main class and the BinarySearchTest is the subclass, it overrides setup and teardown methods. All test methods start with 'test_' prefix thus differentiating helper methods from main methods. The Test::Unit::TestCase class makes the test methods into tests, wrapping them into a suite and running the individual tests. The results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'english_french'
class EnglishFrenchTest < Test::Unit::TestCase
include EnglishFrenchTranslator
def test_simple_word
s = translate("house")
assert_equal("mason", s)
end
def test_word_beginning_with_vowel
s = translate("apple")
assert_equal("pomme", s)
end
def test_two_consonant_word
s = translate("stupid")
assert_equal("stupides", s)
end
end

The tests are run by running the file test_english_french.rb.Sample results for the above test is shown below.

$ ruby test_english_french.rb
Loaded suite test_english_french
Started
FFF
Finished in 0.01091 seconds.

3 tests, 3 assertions, 0 failures, 0 errors

== Shoulda ==
Shoulda is a library rather than a framework which gives the flexibility to write better and easy to understand tests for the Ruby application being tested. Shoulda compliments Test::Unit and RSpec in the sense that it can be used within both of them. Using Shoulda one can provide context to tests so that, tests can be grouped according to a specific feature or scenario.
===Features===

[[File:Capture1.JPG‎|thumb|left|170px|components of Shoulda]]

Shoulda consist of matchers, test-helpers and assertions<ref>http://rubydoc.info/gems/shoulda/2.11.3/frames</ref> -

'''Matchers''' 
Matchers (or more popularly simply [http://en.wikipedia.org/wiki/Macro_(computer_science)#Text_substitution_macros macros]) are Test::Unit- and RSpec-compatible one-liners that test common Rails functionality. The task of developing cumbersome, complex and often erroneous code is made simple with the help of matchers.

'''Helpers''' 
Helpers like ''#context'' and ''#should'' not only gives ''RSpec'' like test blocks in ''Test::Unit'' but also in addition to these, one gets nested contexts and a much more readable syntax.

'''Assertions''' 
Many common Rails testing idioms have been distilled into a set of useful assertions.

 

===Installation===
Shoulda for can be installed for [http://weblog.rubyonrails.org/2010/8/29/rails-3-0-it-s-done| Rails 3.0] version by including the following in the [http://gembundler.com/gemfile.html Gemfile]
<code>
group :test do
gem "shoulda"
gem "rspec-rails", "2.0.0.beta.12"
end
</code> 
===Example===

As far as usage of shoulda is concerned, one can write matchers as follows-

Suppose one is testing for the class ''Post'' on a blog, heres how it is achieved using shoulda::Macthers

<code>
class Post_Test < Test::Unit::TestCase
should belong_to(:user)
should have_many(:tags).through(:taggings) 
should validate_uniqueness_of(:title)
should validate_presence_of(:title)
should validate_numericality_of(:user_id)
end
</code>

Similarly the test for class ''Users'' can be

<code>
class Users_Test < Test::Unit::TestCase
should have_many(:posts) #checking validity of e-mail id 
should_not allow_value("blah").for(:email)
should allow_value("a@b.com").for(:email)
should_not allow_mass_assignment_of(:password)
end
</code>

As can be seen, writing test case for TDD becomes much more elegant and less error prone.

Similarly shoulda::helpers can be written as shown -

Suppose one wants to check the validity of getter method presence for an object, simply an should_have helper can be written like

<code>
context "the create action" do
setup do
@attributes = Posts.attributes_for(:item)
post :create, :item => @attributes
end 
should_create_row Item do |item|
assert_has_attributes @attributes, item #''assert_has_attributes'' - simply a helper method that makes sure the object has getter methods and values corresponding to the key/value pairs in the hash.
end
end
</code>

When this tests are run one gets the some similar following results

<code>
Loaded suite C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample
Started
...F...
Finished in 0.001000 seconds. 
1) Failure:
test: Users_Test Functions should Fail Test. (Post Test) [C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample.rb:33]:
<1> expected but was
<nil>. 
1 tests, 1 assertions, 1 failures, 0 errors, 0 skips 
Test run options: --seed 25476

</code>

The most interesting part of shoulda is the assertions which make writing test code efficient. An example of shoulda::Assertion can be seen as below

<code>
assert_same_elements([:a, :b, :c], [:c, :a, :b]) #checks whether array has same entries
assert_contains(['a', '1'], /\d/) #checks for presence of a digit
assert_contains(['a', '1'], 'a') #checks for presence of letter ''a''
</code>

== RSpec ==
[[File:Capture3.JPG‎|thumb|left|400px|flow of logic in R-Spec]]

RSpec is a Behavioral Driven development tool,created by Dave Astels and Steven Bake <ref>http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial</ref> aimed as test driven development.

RSpec is merging of two projects into one -

application level behaviour described by a Story Framework 
object level behaviour described by a Spec Framework 

The primary aim of RSpec is to drift the focus from unit testing to behavioral testing, i.e. to check if the desired functionality is achieved. It is also used to check for redundancy in code and helps refactoring our code without having to re-write every test.
===Installation===
In order to install RSpec, open a command shell, go to /bin folder in Ruby directory and type
> gem install rspec

===Features===
==== RSpec Story ====
A Story describes the functionality of a specific software feature, and it describes it in a way that is easy to understand from the point of view of a client. In fact a story can be thought of as a conversation between a client and a programmer over some feature of the software. The key points of a story are:- Title, Narrative, Scenario, Givens, Details[http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]
==== Message Expectations ====
A message expectation (a.k.a. mock method)<ref>http://rspec.info</ref> is an expectation that an object should receive a specific message during the execution of an example. This is similar to "Assertions" in test::unit.
==== Group ====
More than one executable example can be grouped into one file.
==== Spec File====
A spec file is a file that contains one or more group examples.
==== describe() and it() methods ====
The describe() method takes an arbitrary number of arguments and returns a sub-class of Spec::Example::ExampleGroup. The it() method takes a single String, an optional Hash and an optional block.

=== Example Test ===
The below code is an example for testing using rspec. The spec file, ruby file and the output are shown. It can be seen that code can be added to the spec file for different test conditions and expectations.

# archery_spec.rb
require 'archery'
describe Archery, "#score" do
it "returns 0 for all mock games" do
archery = Archery.new
20.times { archery.hit(0) }
archery.score.should == 0
end
end

# archery.rb
class Archery
def hit(arrows)
end
def score
0
end
end

$ spec archery_spec.rb --format nested
Archery#score
returns 0 for all mock games
Finished in 0.006535 seconds
1 example, 0 failures

== Cucumber ==
Cucumber is a testing tool that follows the BDD approach of testing. Cucumber written itself in Ruby programming language allows the execution of feature documentation written in natural language often termed as [http://en.wikipedia.org/wiki/User_story user stories]
=== Features of Cucumber ===

==== Terminology of Cucumber====
There are few taxonomy terms related to Cucumber <ref>http://cuke4ninja.com/sec_cucumber_jargon.html</ref> as follows-
[[File:Capture.JPG‎|thumb|left|200px|major components of Cucumber]]
'''Stakeholder''' - A person who gets some value out of the system like an administrator '''Feature''' - A feature is a piece of system functionality that delivers value to one or more stakeholders '''User story''' - It is a rough description of scope for future work used as planning tools. Most common format for the stories are - ''"in order to..."'',''"as a..."'',''"I want"'' '''Feature file''' - It describes a feature or a part of feature with illustrative example of expected results '''Key Example''' - Each feature is illustrated with Key Examples which show what are expected in a given test case '''Scenario''' - Scenario captures one key example for a feature file. It represents how stakeholder gets some value from that system. Example of good scenarios for checking login module includes ''user not signed up'', ''password has expired'' '''Step''' - Steps are domain language phrases which can be combined to write scenarios. They combine a GWT directive with a regular expression to evaluate something and add a simple ruby code which tells the step what should be done further.
 
==== Pattern ====
Cucumber follows a GWT (Given-When-Then) pattern for developing test cases. In the scenarios written for Cucumber, one states what a ''given'' scenario is, ''when'' one is presented with information and ''then'' what should happen so that the logic of information can be validated.

===Example===
Cucumber is a high-level testing tool that defines the feature specs. An typical [[http://www.ultrasaurus.com/sarahblog/2008/12/rails-2-day-3-behavior-driven-development/#spec example]] for a Cucumber Scenario is shown below -
First one need to install the Cucumber gem on Ruby using this simple command
<code>
$gem install cucumber-rails
Successfully installed cucumber-rails-1.0.6
1 gem installed
Installing ri documentation for cucumber-rails-1.0.6...
Installing RDoc documentation for cucumber-rails-1.0.6...
</code>
When installed, a basic Cucumber test is generated using [http://en.wikipedia.org/wiki/Generator_(computer_programming) generator] script
<code>
$script/generate rspec
$script/generate cucumber
force config/database.yml
create config/cucumber.yml
create config/environments/cucumber.rb
create script/cucumber
create features/step_definitions
create features/step_definitions/web_steps.rb
create features/support
create features/support/paths.rb
create features/support/env.rb
exists lib/tasks
create lib/tasks/cucumber.rake
</code>
A feature file is next created with name ''feature_name.featrue'' . the Feature is described in the Feature: directive, followed by the story. The story is written in the format shown in the code: ''As a <role> , I want <feature> , So that <business Value>.''
<code>
$ nano tasklist.feature 
Feature: Tasks 
In order to keep track of tasks
People should be able to
Create a list of tasks
</code>
Each feature can have multiple scenario. One such scenario for the login feature is as shown below
<code>
Scenario: List Tasks
Given that I have created a task "task 1"
When I go to the tasks page
Then I should see "task 1"
</code>
When a scenario is ready following command is issued
<code>
$script/cucumber features/tasklist.feature
0 scenarios
0 steps
</code>
Steps can be added to scenarios, which are combination of a GWT directive, a [http://en.wikipedia.org/wiki/Regular_expression regular expression] and a block of ruby code which states what this step does
<code>
/features/step_definitions$nano tasklist_steps.rb 
Given /^that I have created a task "(.*)"$/ do |desc|
Task.create!(:description => desc)
end
When /^I go to the tasks page$/ do
visit "/tasks"
end
</code>
For more elaborated examples one can refer to the [http://cukes.info/ Cucumber site].

== Other Testing Frameworks==

= Comparison =
Now that the major frameworks have been explained briefly, here is a comparison among them based on few criteria/metrics
 
{|class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;; "cellspacing="0"; border="1"
!style="width:20%"|Metric
!style="width:20%"|Test::Unit
!style="width:20%"|Shoulda
!style="width:20%"|RSpec
!style="width:20%"|Cucumber
|-
| Framework 
| Test Driven Development framework.
| It is an extension to Test::Unit. It has more capabilities and simpler readable syntax compared to Test::Unit.
| Behavior Driven Development framework.
| Behavior Driven Development framework.
|-
| Version<ref>http://ruby-toolbox.com/categories/testing_frameworks.html</ref> 
| 1.2.3
| 2.11.3
| 2.6.0
| 1.0.6
|-

| Website 
| [http://test-unit.rubyforge.org/ Test::Unit] 
| [https://github.com/thoughtbot/shoulda Github -Shoulda] 
| [http://rspec.info/ RSpec] 
| [http://cukes.info/ Cucumber] 
|-
| Base Library <ref>http://en.wikipedia.org/wiki/Unit-testing_frameworks_for_Ruby_(programming_language)</ref> 
| Yes 
| No 
| No 
| No 
|-
| Allows nested setup <ref>http://nested-layouts.rubyforge.org/</ref>
| No 
| Yes 
| Yes 
| Yes 
|-
| Opaqueness/Expressiveness 
| Opaque to a certain extent, low level coding required 
| More descriptive 
| More expressive compared to Unit::test and shoulda. 
| More expressive compared to Unit::test and shoulda 
|-
| Run Times 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
|-
| General Use 
| Unit testing 
| Unit testing especially on the Rails framework [http://www.linuxjournal.com/magazine/forge-testing-rails-applications-shoulda] 
| Unit testing 
| Integration testing 
|}

= Conclusion =
The case as to which is the best framework, depends on scenario for which that testing framework is used. In general,[http://ruby-toolbox.com/categories/testing_frameworks.html stats] based on number of [https://github.com/ Github] views suggests, Cucumber is the industry favored testing framework for Ruby. The reason to this accounts for easy-to-use and easy-to-understand syntax and the ability to focus on only one test at a time. RSpec comes second (again in terms of [http://ruby-toolbox.com/categories/testing_frameworks.html popularity and Github views]) followed by others.

= References =
<references/>

CSC/ECE 517 Fall 2011/ch2 2e gp

2011-09-22T03:02:15Z

Payyapp: /* Comparison */

='''Testing Frameworks for Ruby'''=

This page serves as a knowledge source for understanding the different Testing Frameworks available for [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]. 

__TOC__
= Introduction =
No code is perfect from the word go! Testing plays an important role in System Development Life Cycle. During testing, one follows a taxonomic procedure to uncover defects at various stages. A test framework provides various Test Types, Test Phases, Test Models, Test Metrics and acts as a guideline as to how to perform effective testing <ref> http://www.scribd.com/doc/15909730/Software-Testing-Framework </ref>. Various testing tools are available for [http://en.wikipedia.org/wiki/Ruby Ruby]language, each having some unique features over others. Here is a brief introduction and feature comparisons of popular testing frameworks.

== Testing Approaches ==
[[File:Capture5.JPG‎|thumb|right|200px|flow of test driven developmental approach]]
Before delving into testing for Ruby, in general, these are the followed approaches in industry today

=== Test Driven Development ===

This strategy, (abbreviated as TDD) <ref> http://en.wikipedia.org/wiki/Test-driven_development </ref>, though cumbersome due to its methodology develops efficient code. First a unit test is written for a function, even before the code for that function is developed. Based on this test minimal code is developed to ensure the test succeeds; if not the code is modified until test run successfully. In this iterative approach, effort is made to ensure flawless code is developed.

=== Behavior Driven Development ===
BDD <ref> http://en.wikipedia.org/wiki/Behavior_Driven_Development </ref> as its popularly know, upholds the traditional iterative workflow of Test Driven Development, but it focuses on defining behaviors that is easy to understand to naive people (with no programming background) by writing tests in natural language. This approach focuses more on looking at code development from a behavioral abstraction. For example testing the code for a recipe belonging to a category of a cookbook, in BDD would be something like 'A recipe can't be without a category'

= Unit Testing =
[http://en.wikipedia.org/wiki/Unit_testing Unit Testing] is a method by which one can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written.
== Test::Unit ==
[[File:Capture4.JPG‎|thumb|right|400px|screen capture of TestUnit console in [http://en.wikipedia.org/wiki/RubyMine RubyMine IDE]]]

The in-built, ready to use unit testing mechanism for Ruby is called [http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit].It belongs to the XUnit family unit testing framework. It has a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests are bundled separately in a test class in the code it is aimed to test.
=== Features ===
This salient features of the Test::Unit Framework are:-
==== Assertions ====
One can use Test::Unit to make [http://en.wikipedia.org/wiki/Assertion_(computing) assertions]. The test is successful if the assertion is true and fails if the assertion is false. All the assertion methods provided by test::unit can be found at [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Test::Unit::Assertions].

{|border=1 cellspacing=0 cellpadding=5
| assert( boolean, [message] )
| True if ''boolean''
|-
| assert_equal( expected, actual, [message] ) assert_not_equal( expected, actual, [message] )
| True if ''expected == actual''
|-
| assert_raise( Exception,... ) {block} assert_nothing_raised( Exception,...) {block}
| True if the block raises (or doesn't) one of the listed exceptions.
|-
|}

==== Test-Fixtures ====
Using a test fixture, one can initialize (and cleanup) the common set of data for two or more tests hence eliminating unnecessary duplication. Fixtures are written in the setup() and teardown() methods.
==== Test-Suite ====
As unit tests increase in number for a given project, it becomes tough running them one at a time. It is hence useful to combine a bunch of related test cases and run them as batch. Test::Unit provides a class called TestSuite for this purpose<ref>http://www.ensta-paristech.fr/~diam/ruby/online/ruby-doc-stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/TestSuite.html</ref>.

=== Example Test ===
The Test::Unit::TestCase class is the main class and the BinarySearchTest is the subclass, it overrides setup and teardown methods. All test methods start with 'test_' prefix thus differentiating helper methods from main methods. The Test::Unit::TestCase class makes the test methods into tests, wrapping them into a suite and running the individual tests. The results are collected into Test::Unit::TestResult object.

require 'test/unit'
require 'english_french'
class EnglishFrenchTest < Test::Unit::TestCase
include EnglishFrenchTranslator
def test_simple_word
s = translate("house")
assert_equal("mason", s)
end
def test_word_beginning_with_vowel
s = translate("apple")
assert_equal("pomme", s)
end
def test_two_consonant_word
s = translate("stupid")
assert_equal("stupides", s)
end
end

The tests are run by running the file test_english_french.rb.Sample results for the above test is shown below.

$ ruby test_english_french.rb
Loaded suite test_english_french
Started
FFF
Finished in 0.01091 seconds.

3 tests, 3 assertions, 0 failures, 0 errors

== Shoulda ==
Shoulda is a library rather than a framework which gives the flexibility to write better and easy to understand tests for the Ruby application being tested. Shoulda compliments Test::Unit and RSpec in the sense that it can be used within both of them. Using Shoulda one can provide context to tests so that, tests can be grouped according to a specific feature or scenario.
===Features===

[[File:Capture1.JPG‎|thumb|left|170px|components of Shoulda]]

Shoulda consist of matchers, test-helpers and assertions<ref>http://rubydoc.info/gems/shoulda/2.11.3/frames</ref> -

'''Matchers''' 
Matchers (or more popularly simply [http://en.wikipedia.org/wiki/Macro_(computer_science)#Text_substitution_macros macros]) are Test::Unit- and RSpec-compatible one-liners that test common Rails functionality. The task of developing cumbersome, complex and often erroneous code is made simple with the help of matchers.

'''Helpers''' 
Helpers like ''#context'' and ''#should'' not only gives ''RSpec'' like test blocks in ''Test::Unit'' but also in addition to these, one gets nested contexts and a much more readable syntax.

'''Assertions''' 
Many common Rails testing idioms have been distilled into a set of useful assertions.

 

===Installation===
Shoulda for can be installed for [http://weblog.rubyonrails.org/2010/8/29/rails-3-0-it-s-done| Rails 3.0] version by including the following in the [http://gembundler.com/gemfile.html Gemfile]
<code>
group :test do
gem "shoulda"
gem "rspec-rails", "2.0.0.beta.12"
end
</code> 
===Example===

As far as usage of shoulda is concerned, one can write matchers as follows-

Suppose one is testing for the class ''Post'' on a blog, heres how it is achieved using shoulda::Macthers

<code>
class Post_Test < Test::Unit::TestCase
should belong_to(:user)
should have_many(:tags).through(:taggings) 
should validate_uniqueness_of(:title)
should validate_presence_of(:title)
should validate_numericality_of(:user_id)
end
</code>

Similarly the test for class ''Users'' can be

<code>
class Users_Test < Test::Unit::TestCase
should have_many(:posts) #checking validity of e-mail id 
should_not allow_value("blah").for(:email)
should allow_value("a@b.com").for(:email)
should_not allow_mass_assignment_of(:password)
end
</code>

As can be seen, writing test case for TDD becomes much more elegant and less error prone.

Similarly shoulda::helpers can be written as shown -

Suppose one wants to check the validity of getter method presence for an object, simply an should_have helper can be written like

<code>
context "the create action" do
setup do
@attributes = Posts.attributes_for(:item)
post :create, :item => @attributes
end 
should_create_row Item do |item|
assert_has_attributes @attributes, item #''assert_has_attributes'' - simply a helper method that makes sure the object has getter methods and values corresponding to the key/value pairs in the hash.
end
end
</code>

When this tests are run one gets the some similar following results

<code>
Loaded suite C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample
Started
...F...
Finished in 0.001000 seconds. 
1) Failure:
test: Users_Test Functions should Fail Test. (Post Test) [C:/Users/Girish/Desktop/CSC517/Workspace/Ruby/Wikiexample.rb:33]:
<1> expected but was
<nil>. 
1 tests, 1 assertions, 1 failures, 0 errors, 0 skips 
Test run options: --seed 25476

</code>

The most interesting part of shoulda is the assertions which make writing test code efficient. An example of shoulda::Assertion can be seen as below

<code>
assert_same_elements([:a, :b, :c], [:c, :a, :b]) #checks whether array has same entries
assert_contains(['a', '1'], /\d/) #checks for presence of a digit
assert_contains(['a', '1'], 'a') #checks for presence of letter ''a''
</code>

== RSpec ==
[[File:Capture3.JPG‎|thumb|left|400px|flow of logic in R-Spec]]

RSpec is a Behavioral Driven development tool,created by Dave Astels and Steven Bake <ref>http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial</ref> aimed as test driven development.

RSpec is merging of two projects into one -

application level behaviour described by a Story Framework 
object level behaviour described by a Spec Framework 

The primary aim of RSpec is to drift the focus from unit testing to behavioral testing, i.e. to check if the desired functionality is achieved. It is also used to check for redundancy in code and helps refactoring our code without having to re-write every test.
===Installation===
In order to install RSpec, open a command shell, go to /bin folder in Ruby directory and type
> gem install rspec

===Features===
==== RSpec Story ====
A Story describes the functionality of a specific software feature, and it describes it in a way that is easy to understand from the point of view of a client. In fact a story can be thought of as a conversation between a client and a programmer over some feature of the software. The key points of a story are:- Title, Narrative, Scenario, Givens, Details[http://blog.emson.co.uk/2008/06/understanding-rspec-stories-a-tutorial/]
==== Message Expectations ====
A message expectation (a.k.a. mock method)<ref>http://rspec.info</ref> is an expectation that an object should receive a specific message during the execution of an example. This is similar to "Assertions" in test::unit.
==== Group ====
More than one executable example can be grouped into one file.
==== Spec File====
A spec file is a file that contains one or more group examples.
==== describe() and it() methods ====
The describe() method takes an arbitrary number of arguments and returns a sub-class of Spec::Example::ExampleGroup. The it() method takes a single String, an optional Hash and an optional block.

=== Example Test ===
The below code is an example for testing using rspec. The spec file, ruby file and the output are shown. It can be seen that code can be added to the spec file for different test conditions and expectations.

# archery_spec.rb
require 'archery'
describe Archery, "#score" do
it "returns 0 for all mock games" do
archery = Archery.new
20.times { archery.hit(0) }
archery.score.should == 0
end
end

# archery.rb
class Archery
def hit(arrows)
end
def score
0
end
end

$ spec archery_spec.rb --format nested
Archery#score
returns 0 for all mock games
Finished in 0.006535 seconds
1 example, 0 failures

== Cucumber ==
Cucumber is a testing tool that follows the BDD approach of testing. Cucumber written itself in Ruby programming language allows the execution of feature documentation written in natural language often termed as [http://en.wikipedia.org/wiki/User_story user stories]
=== Features of Cucumber ===

==== Terminology of Cucumber====
There are few taxonomy terms related to Cucumber <ref>http://cuke4ninja.com/sec_cucumber_jargon.html</ref> as follows-
[[File:Capture.JPG‎|thumb|left|200px|major components of Cucumber]]
'''Stakeholder''' - A person who gets some value out of the system like an administrator '''Feature''' - A feature is a piece of system functionality that delivers value to one or more stakeholders '''User story''' - It is a rough description of scope for future work used as planning tools. Most common format for the stories are - ''"in order to..."'',''"as a..."'',''"I want"'' '''Feature file''' - It describes a feature or a part of feature with illustrative example of expected results '''Key Example''' - Each feature is illustrated with Key Examples which show what are expected in a given test case '''Scenario''' - Scenario captures one key example for a feature file. It represents how stakeholder gets some value from that system. Example of good scenarios for checking login module includes ''user not signed up'', ''password has expired'' '''Step''' - Steps are domain language phrases which can be combined to write scenarios. They combine a GWT directive with a regular expression to evaluate something and add a simple ruby code which tells the step what should be done further.
 
==== Pattern ====
Cucumber follows a GWT (Given-When-Then) pattern for developing test cases. In the scenarios written for Cucumber, one states what a ''given'' scenario is, ''when'' one is presented with information and ''then'' what should happen so that the logic of information can be validated.

===Example===
Cucumber is a high-level testing tool that defines the feature specs. An typical [[http://www.ultrasaurus.com/sarahblog/2008/12/rails-2-day-3-behavior-driven-development/#spec example]] for a Cucumber Scenario is shown below -
First one need to install the Cucumber gem on Ruby using this simple command
<code>
$gem install cucumber-rails
Successfully installed cucumber-rails-0.3.0
1 gem installed
Installing ri documentation for cucumber-rails-0.3.0...
Installing RDoc documentation for cucumber-rails-0.3.0...
</code>
When installed, a basic Cucumber test is generated using [http://en.wikipedia.org/wiki/Generator_(computer_programming) generator] script
<code>
$script/generate rspec
$script/generate cucumber
force config/database.yml
create config/cucumber.yml
create config/environments/cucumber.rb
create script/cucumber
create features/step_definitions
create features/step_definitions/web_steps.rb
create features/support
create features/support/paths.rb
create features/support/env.rb
exists lib/tasks
create lib/tasks/cucumber.rake
</code>
A feature file is next created with name ''feature_name.featrue'' . the Feature is described in the Feature: directive, followed by the story. The story is written in the format shown in the code: ''As a <role> , I want <feature> , So that <business Value>.''
<code>
$ nano tasklist.feature 
Feature: Tasks 
In order to keep track of tasks
People should be able to
Create a list of tasks
</code>
Each feature can have multiple scenario. One such scenario for the login feature is as shown below
<code>
Scenario: List Tasks
Given that I have created a task "task 1"
When I go to the tasks page
Then I should see "task 1"
</code>
When a scenario is ready following command is issued
<code>
$script/cucumber features/tasklist.feature
0 scenarios
0 steps
</code>
Steps can be added to scenarios, which are combination of a GWT directive, a [http://en.wikipedia.org/wiki/Regular_expression regular expression] and a block of ruby code which states what this step does
<code>
/features/step_definitions$nano tasklist_steps.rb 
Given /^that I have created a task "(.*)"$/ do |desc|
Task.create!(:description => desc)
end
When /^I go to the tasks page$/ do
visit "/tasks"
end
</code>

= Comparison =
Now that the major frameworks have been explained briefly, here is a comparison among them based on few criteria/metrics
 
{|class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;; "cellspacing="0"; border="1"
!style="width:20%"|Metric
!style="width:20%"|Test::Unit
!style="width:20%"|Shoulda
!style="width:20%"|RSpec
!style="width:20%"|Cucumber
|-
| Framework 
| Test Driven Development framework.
| It is an extension to Test::Unit. It has more capabilities and simpler readable syntax compared to Test::Unit.
| Behavior Driven Development framework.
| Behavior Driven Development framework.
|-
| Version<ref>http://ruby-toolbox.com/categories/testing_frameworks.html</ref> 
| 1.2.3
| 2.11.3
| 2.6.0
| 1.0.6
|-

| Website 
| [http://test-unit.rubyforge.org/ Test::Unit] 
| [https://github.com/thoughtbot/shoulda Github -Shoulda] 
| [http://rspec.info/ RSpec] 
| [http://cukes.info/ Cucumber] 
|-
| Base Library <ref>http://en.wikipedia.org/wiki/Unit-testing_frameworks_for_Ruby_(programming_language)</ref> 
| Yes 
| No 
| No 
| No 
|-
| Allows nested setup
| No 
| Yes 
| Yes 
| Yes 
|-
| Opaqueness/Expressiveness 
| Opaque to a certain extent, low level coding required 
| More descriptive 
| More expressive compared to Unit::test and shoulda. 
| More expressive compared to Unit::test and shoulda 
|-
| Run Times 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| Faster than RSpec because it has fewer features and hence lesser code to run 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
| More features but comes at a cost, run time slower than shoulda and test::unit. 
|-
| General Use 
| Unit testing 
| Unit testing especially on the Rails framework [http://www.linuxjournal.com/magazine/forge-testing-rails-applications-shoulda] 
| Unit testing 
| Integration testing 
|}

= Conclusion =
The case as to which is the best framework, depends on scenario for which that testing framework is used. In general,[http://ruby-toolbox.com/categories/testing_frameworks.html stats] based on [https://github.com/ Github] downloads suggests, Cucumber is the industry favored testing framework for Ruby. The reason to this accounts for easy-to-use and easy-to-understand syntax and the ability to focus on only one test at a time. RSpec comes second (again in terms of [http://ruby-toolbox.com/categories/testing_frameworks.html popularity and Github views]) followed by others.

= References =
<references/>