Archive for the ‘tdd’ Category

When to uses mock objects ?

In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways

Wikipedia

Use mocks when you to :

  • improve test performances.
  • Remove dependencies of external systems.
  • control the behavior of a method.

Via MockFight

The easiest rubinius core library patch tutorial ever.

This is a 5 minutes introduction to create a core patch to Rubinius.

  1. Write a core library patch to Rubinius is really easy. First we need to decide what we want to write. Run the specs and find a bug, or write your own specs. Im going to write my own spec. I decide to implement the missing spec hypotenuse form Math Module
  2. A bit of Test driven development :
    1. Find the math specs file : RUBINIUS_HOME/spec/core/math_spec.rb
    2. Write the spec :
      1. create the describe :
        describe "Math#hypot" doend
      2. Add the basic cases :
        it "return x**2+y**2" do      
           Math.hypot(0,0).should_be_close(0.0,TOLERANCE)Math.hypot(2,10).should_be_close( 10.1980390271856 ,TOLERANCE)
           Math.hypot(5000,5000).should_be_close(7071.06781186548 ,TOLERANCE)
           Math.hypot(0.0001,0.0002).should_be_close(0.000223606797749979,TOLERANCE)
           Math.hypot(-2,-10).should_be_close(Math.hypot(2,10),TOLERANCE)
           Math.hypot(2,10).should_be_close(Math.hypot(10,2),TOLERANCE)
        end
      3. Add exceptional cases :
         it "raise an ArgumentError exception if the argument are  the wrong type" do 
           should_raise(ArgumentError){Math.hypot("test","test2")}
        end 
         it "raise an TypeError exception if the argument is nill" do  
          should_raise(ArgumentError){Math.hypot(nil)}
        end 
    3. run the specs. ruby spec/core/math_spec.rb. Umm 3 fails
  3. Ok, lets coding
    1. Find the math module : RUBINIUS_HOME/kernel/core/math.rb
    2. Write the method
      1. def hypot(x,y)
            sqrt(x**2 + y**2); 
        end
      2. rebuild the core: rake build:core
      3. run the test again … ummm two fails. not so bad.
    3. Lets code again :
      1. The method :
          def hypot(x,y)     raise ArgumentError unless x.kind_of? Numeric or y.kind_of? Numericsqrt(x**2 + y**2)end
      2. rebuild the core
      3. re run the specs … 0 fails !!
      4. Thats all.
    4. No !! thats not al. As Tony Targonski point in the comments we have a bug. Ok lets write a case for the bug.

RSpec and BDD.

My take on it is that doing BDD is the same as doing TDD well. The problem that I’ve seen with TDD is people tend to think of it as testing, as verification but it’s specification not verification, for several years now. But that’s a hard sell when you’re constantly talking about tests, about assertions, you’re extending something called TestCase, and writing methods that start with “test”. Now, we don’t have to do that anymore in most cases because we just put an annotation on that says “test”. So, it’s hard to get away from that baggage. It’s hard to stop thinking about them as being tests when we are constantly talking about them as tests. And that’s where BDD comes in to make a break from that and start talking in a specification-centric nomenclature, verification-centric vocabulary rather than testing-centric.

 

Dave Astels.

 

Follow

Get every new post delivered to your Inbox.