CSC/ECE 517 Fall 2010/ch1 1f vn: Difference between revisions
Thatvamasi (talk | contribs) |
Thatvamasi (talk | contribs) |
||
Line 101: | Line 101: | ||
To install RSpec, open a command shell, go to /bin folder in Ruby directory and type<br> | To install RSpec, open a command shell, go to /bin folder in Ruby directory and type<br> | ||
> gem install rspec | > gem install rspec | ||
==Terms & Definitions== | |||
Here are some terms which are used frequently while working with RSpec. | |||
# <b>subject code</b> - The code whose behavior is specified using RSpec | |||
# <b>expectation</b> - The expected behavior of subject code is expressed using expectation | |||
# <b>code example</b> - An executable example containing the subject code and the expectations | |||
# <b>example group</b> - A group of code examples | |||
# <b>spec file</b> - A file which contains one or more example groups | |||
==Example== | ==Example== |
Revision as of 21:34, 8 September 2010
Introduction
Unit testing is a method by which we can isolate and test a unit functionality of the program, typically individual methods during and long after the code is written. Unit testing frameworks provides us with constructs which simplifies the process of unit testing. This chapter walks through three different unit testing frameworks available for Ruby, explains how to use them with examples, and compares them with one another. The three commonly used unit testing frameworks for ruby are
- Test::Unit
- Shoulda
- RSpec
Test::Unit
Ruby comes with an in-built, ready to use unit testing framework called Test::Unit. It is a XUnit type framework and typically have a setup method for initialization, a teardown method for cleanup and the actual test methods itself. The tests themselves are bundled separately from the code it is testing.
Test Fixture
Test fixture represents the initial environment setup(eg. initialization data) and the expected outcome of the tests for that environment. This is typically done in the setup()/teardown() methods and it helps to separate test initialization/cleanup from the actual tests. It also helps to reuse the same fixture for more than one tests.
From example, consider a method prime_check(num) which takes a number as input and outputs whether it is prime number or not. In order to unit test this method we will be needing the following fixture containing a 2-dimensional array with a number and the expected output of whether it is prime or not.
def setup @NUMBERS = [[3,true], [4,false], [7,true], [10,false]] end
Assertions
The core part of test::unit framework is the ability to assert a statement of expected outcome. If an assert statement is correct then the test will proceed, otherwise the test will fail. Test::unit provides a bunch of assert methods for this purpose like:
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. |
For the full list of assertion methods provided by test::unit refer to test::unit assertions
Example
The test case class extends the Test::Unit::TestCase class. The test methods should start with 'test' prefix. This helps in isolating the test methods from the helper methods if any.
require 'test/unit' require 'binarysearch' class BinarySearch < Test::Unit::TestCase def setup @input_array = [1,2,3,4,5] end def test_success_left_half assert_equal(binary_search(@input_array,1),true) end def test_success_right_half assert_equal(binary_search(@input_array,5),true) end def test_success_middle assert_equal(binary_search(@input_array,3),true) end def test_failure assert_equal(binary_search(@input_array,6),false) end def teardown #nothing to do here end end
Test Suite
Shoulda
Shoulda is not a testing framework by itself. It extends the Test::Unit framework with the idea of matchers, helpers and assertions
RSpec
Now let us consider about RSpec Testing Framework in detail.
Background
Behaviour Driven Development (BDD) is an Agile development process that comprises aspects of Acceptance Test Driven Planning, Domain Driven Design and Test Driven Development (TDD). RSpec is a Behavioural Driven Development (BDD) tool aimed at Test Driven Development, originally created by Dave Astels and Steven Baker. However David Chelimsky is really the gatekeeper of the RSpec project.
Traditionally tests have been written using a Unit Test framework like JUnit, NUnit or RUnit. However it is easy to spending a lot of time writing tests that test every unit of code in your software system, what RSPec does is to provide a subtle shift of focus from Unit testing to Behaviour testing or Behaviour Driven Development (BDD). By focusing on the behaviour of the system it helps clarify in our minds what the system should actually be doing. It also means that our energy is directed at more ‘useful’ tests. Useful tests, cover what the system should be doing and build in enough redundancy so that it should be easy to refactor our code without having to re-write every test.
RSpec is really two projects merged into one. The RSpec project pages describes these merged projects as:
- a Story Framework for describing behaviour at the application level
- a Spec Framework for describing behaviour at the object level
Dan North created rbehave which is the Story Framework and David Chelimsky created the Spec Framework. By encompassing two frameworks RSpec equips a programmer with a thorough set of testing tools, allowing you to think about your software problem from a number of perspectives.
Prerequisites
The prerequisites are
- Ruby 1.8.4 or later
- RSpec Gem (latest)
To install Ruby, please visit http://www.ruby-lang.org
To install RSpec, open a command shell, go to /bin folder in Ruby directory and type
> gem install rspec
Terms & Definitions
Here are some terms which are used frequently while working with RSpec.
- subject code - The code whose behavior is specified using RSpec
- expectation - The expected behavior of subject code is expressed using expectation
- code example - An executable example containing the subject code and the expectations
- example group - A group of code examples
- spec file - A file which contains one or more example groups