CSC/ECE 517 Fall 2010/ch1 1f TU: Difference between revisions
Line 407: | Line 407: | ||
== Comparison of Test::Unit, Shoulda, RSpec == | == Comparison of Test::Unit, Shoulda, RSpec == | ||
{|cellspacing="0" border="1" | {|cellspacing="0" border="1" |
Revision as of 19:52, 7 September 2010
Unit-testing frameworks for Ruby
Unit Testing
A unit is the smallest building block of a software. Such a unit can be: a class, a method, an interface etc. Unit testing is the process of validating such units of code.
Benefits
Some of the benefits are:
- Proof of your code.
- Better design - Thinking about the tests can help us to create small design elements, thereby improving the modularity and reusability of units.
- Safety net on bugs - Unit tests will confirm that while refactoring no additional errors were introduced.
- Relative cost - It helps to detect and remove defects in a more cost effective manner compared to the other stages of testing.
- Individual tests - Enables us to test parts of a source code in isolation.
- Less compile-build-debug cycles - Makes debugging more efficient by searching for bugs in the probable code areas.
- Documentation - Designers can look at the unit test for a particular method and learn about its functionality.
Unit-testing frameworks
Unit Test Framework is a software tool to support writing and running unit test.
The above diagram shows the relationships of unit tests to production code. Application is built from objects linked together. The unit test uses this application's objects but exists inside the unit test framework.
List of most popular unit testing frameworks for Ruby
- Test::Unit
- RSpec
- Shoulda
- Cucumber
Simple application code in Ruby
Let us write a Calculator class in a file called calculator.rb. It has four methods addition, subtraction, multiplication and division. Later in the chapter we shall write tests in each of the above frameworks respectively.
class Calculator attr_writer :number1 attr_writer :number2 def initialize(number1,number2) @number1 = number1 @number2 = number2 end #-----------Addition of two numbers----------------# def addition result = @number1 + @number2 return result end #----------Subtraction of two numbers--------------# def subtraction result= @number1 - @number2 return result end #----------Multiplication of two numbers------------# def multiplication result= @number1 * @number2 return result end #-----------Division of two numbers-------------------# def division result = @number1 / @number2 return result end end
Test::Unit
Features of Test::Unit
- Assertions
- An assertion statement specifies a condition that you expect to hold true at some particular point in your program. If that condition does not hold true, the assertion fails. An error is propagated with pertinent information so that you can go back and make your assertion succeed.
- Test Fixture
- A test fixture is all the things we need to have in place in order to run a test and expect a particular outcome. Sometimes it is also knows as the test context.
- Test Method
- A test method is a definitive procedure that produces a test result. Add a method that begins with "test" to your class.
- Test Runners
- To run the test class and view any failures that occur during the run we need a Test Runner. Examples -Test::Unit::UI::Console::TestRunner, Test::Unit::UI::GTK::TestRunner, etc.
- Test Suite
- A collection of tests which can be run.
Installing Test::Unit
Ruby 1.8 comes preinstalled with Test::Unit framework.
Usage
The general idea behind unit testing is that you write a test method that makes certain assertions about your code, working against a test fixture. The results of a run are gathered in a test result and displayed to the user through some UI. To write a test, follow these steps:
- require ‘test/unit’ in your test script.
- Create a class that subclasses Test::Unit::TestCase.
- Add a method that begins with "test" to your class.
- Make assertions in your test method.
- Optionally define setup and/or teardown to set up and/or tear down your common test fixture.
- Run your test as Test::Unit Test.
Example of a test class
require "calculator" require "test/unit" class TC_Calculator < Test::Unit::TestCase def test_addition assert_equal(8,Calculator.new(3,4).addition) end def test_subtraction assert_same(1,Calculator.new(4,3).subtraction) end def test_multiplication assert_not_same(12,Calculator.new(3,4).multiplication) end def test_division assert_not_equal(5,Calculator.new(8,2).division) end end
If we run this test, here is how it'll look like -
Shoulda
Features of Shoulda
- It is a library that allows us to write better and more understandable tests for your Ruby application.
- It overdrives Test::Unit framework.
- It allows to run test with the help of Test::Unit Configurations.
- It provide us Helpers like context and should in the form of text blocks.We can write tests name in simple sentences rather following any naming conventions.
- With the help of Macros we can generate hundred lines of codes.It also ensures that our application is confirmed to the best practice.
Installing Shoulda
If your Environment path is set to " ...\Ruby\bin" then open command prompt and run gem install shoulda.
Usage
So here is our class "TC_Calculator_Shoulda" which inherits "Test::Unit::TestCase".
- Add require"rubygems" and require "shoulda" to the script.
- Create a context
- Define method starting with should and give an description to the method.
- Create assertions to test the application objects.
require "rubygems" require "calculator" require "test/unit" require "shoulda" class TC_Calculator_Shoulda < Test::Unit::TestCase context "Calculate" do should "addition of two numbers " do assert_equal 8,Calculator.new(3,4).addition end should "subtraction of two numbers " do assert_equal 1,Calculator.new(4,3).subtraction end should "multiplication of two numbers" do assert_equal 12,Calculator.new(3,4).multiplication end should "division of two numbers" do assert_equal 4,Calculator.new(12,3).division end end end
When we run above test as "Ruby Application" we will get the output as follows.
Loaded suite tc__calculator__shoulda Started F... Finished in 0.064 seconds. 1) Failure: test: Calculate should addition of two numbers . (TC_Calculator_Shoulda) <8> expected but was <7>. 4 tests, 4 assertions, 1 failures, 0 errors
RSpec
Features of RSpec
- Establishing behavior - Allows developers to write system requirements in a Ruby format first and then write Ruby code for the particular features of those requirements.
- BDD mandates that developers write tests for each step of the process, which leads to cleaner code. The BDD process begins with the development team creating a scenario, for which they describe each feature. The initial scenario inevitably fails. The team subsequently defines each step (iterative test) and writes the application code for each feature. They also refactor the code when the scenario passes each step.
Installing RSpec
If your Environment path is set to " ...\Ruby\bin" then open command prompt and run gem install rspec.
Usage
Initial spec
You start by describing what your application, method or class should behave like. Let us create our first specification file:
require "calculator" describe "TheCalculator's", "basic calculating" do it "should add two numbers correctly" do it "should subtract two numbers correctly" do it "should multiply two numbers correctly" do it "should divide two numbers correctly" do #... end
What do we have here? First, at line 2 we defined a context for our test, using RSpec's describe block. Furthermore we have four behaviors/expectations (it "should ..." -blocks), defining what we expect our system to behave like.
We can run this specification using the spec command:
$ spec unit_test.rb
produces:
**** Pending: TheCalculator's basic calculating should add two numbers correctly (Not Yet Impl emented) ./21file.rb:5 TheCalculator's basic calculating should subtract two numbers correctly (Not Yet Implemented) ./21file.rb:7 TheCalculator's basic calculating should multiply two numbers correctly (Not Yet Implemented) ./21file.rb:9 TheCalculator's basic calculating should divide two numbers correctly (Not Yet I mplemented) ./21file.rb:11 Finished in 0.021001 seconds 4 examples, 0 failures, 4 pending
Establishing behavior
Isn't it cool? Executing the tests echoes our expectations back at us, telling us that each has yet to be implemented. This is forcing/establishing behavior. We know that all calculator's must perform the above functions. We don't know how we're going to design this yet, but the tests will derive our design.
Writing the application code
At the very end, you write the application code, and fire up the tests to check, if it behaves the way you wanted while writing the tests… but we're getting ahead of ourself.
Developing the code
Let's go a step further and associate code blocks with our expectations.
require "calculator" describe "TheCalculator's", "basic calculating" do before(:each) do @cal = Calculator.new(6,2) end it "should add two numbers correctly" do @cal.addition.should == 8 end it "should subtract two numbers correctly" do @cal.subtraction.should == 4 end it "should multiply two numbers correctly" do @cal.multiplication.should == 11 end it "should divide two numbers correctly" do @cal.division.should == 3 end end
Note that creating a Calculator object for each of our expectations will create duplication in the specification. This can be fixed using a before stanza in the specification. It allows us to run code before expectations are executed.
Let us run it:
produces:
Spec::Expectations::ExpectationNotMetError: expected: 11, got: 12 (using ==) ./unit_test.rb:17
Uh-oh! The third expectation did not meet. See how the error message uses the fact that the expectation knows both the expected and actual values.
In eclipse RSpec will generate a nice description text for you when an expectation is not met.
RSpec is about Behavior Driven Development. It's about encouraging conversation about testing and looking at it in different ways. It's about illuminating the design, specification, collaboration and documentation aspects of tests, and thinking of them as executable examples of behavior.
Cucumber
Features of Cucumber
- Its a Behavior Driven Development(BDD) tool for Ruby.
- It focuses on story styling plain English Text.
- It follows GWT(Given,When,Then) pattern
Installing Cucumber
If your Environment path is set to " ...\Ruby\bin" then open command prompt and run gem install cucumber.
Usage
Let us first create a feature file to describe about our requirements
Feature: Addition In order perform addition of two numbers As a user I want the sum of two numbers Scenario: Add two numbers Given I have entered <input1> And I have entered <input2> When I give add Then The result should be <output>
Then we will create a ruby file to give a code implementation
require 'calculator' Before do @input1=3 @input2=4 end Given /^I have entered <input(\d+)>$/ do |arg1| @calc = Calculator.new(@input1,@input2) end When /^I give add$/ do @result = @calc.addition end Then /^The result should be <output>$/ do puts @result end
Now if we run the feature file we will get the following
Feature: Addition In order perform addition of two numbers As a user I want the sum of two numbers Scenario: Add two numbers # calculator.feature:7 Given I have entered <input1> # addition.rb:8 And I have entered <input2> # addition.rb:8 When I give add # addition.rb:12 7 Then The result should be <output> # addition.rb:16 1 scenario (1 passed) 4 steps (4 passed) 0m0.010s
Comparison of Test::Unit, Shoulda, RSpec
Test::Unit | Shoulda | RSpec |
---|---|---|
Test::Unit is a testing framework provided by Ruby.It is based on Test Driven Development. | Shoulda is an extension to Test::Unit. It is basically Test::Unit with more capabilities and simpler readable syntax. |
RSpec is a Behavior Driven Development framework provided by Ruby. |
Test::Unit provides assertions,test methods like setup,teardown,test fixtures,test runners and test suites | Shoulda provide macros,helpers like context and should,matchers | RSpec provides a Domain Specific Language to express the behavior of code.Basically RSpec is TDD embraced with documentation. |
Test::Unit does not allow nested setup and nested teardown though multiple setup methods and teardown methods are provided in Test::Unit 2.0 | Shoulda allows nested contexts which helps to create different environment for different set of tests. | RSpec allows nested describe structure. |
Conclusion
I like RSpec best since I find the output to be most readable. I love the pending keyword, which allows me to set up the tests to be written later on. I find it helps focus on exactly one test and one failure. Shoulda would be our second choice because the tests are just as readable as RSpec, even if the output takes some learning to read.
Comparison of run times
The following are the run times for these three frameworks testing the same calculator class with 4 succesful tests -
RSpec
- Finished in 0.023002 seconds
- 4 examples, 0 failures
Shoulda
- Finished in 0.002 seconds.
- 4 tests, 4 assertions, 0 failures, 0 errors
Test::unit
- Finished in 0.001 seconds.
- 4 tests, 4 assertions, 0 failures, 0 errors