Floehopper: Tag mocking

The Difference between Mocks and Stubs

James Mead — Mon, 11 Sep 2006 02:59:00 +0000

Some recent converstations have made me realise that a lot of people are confused by the difference between mocking and stubbing. I’ve realised that I’ve only added to the confusion by calling part of the Mocha library, Stubba.

The difference between mocking and stubbing

Stubbing a method is all about replacing the method with code that returns a specified result (or perhaps raises a specified exception). Mocking a method is all about asserting that a method has been called (perhaps with particular parameters).

If you think about it, it’s difficult (or impossible?) to do mocking without stubbing – you need to return from the mocked method, so that the code under test can complete execution. So mocking libraries tend to implicitly or explicitly allow you to do stubbing.

Mocking and stubbing with Mocha

To stub a method, use the stubs method. To mock a method, use the expects method.

The difference between Mocha and Stubba

Mocha is a traditional mocking library very much in the JMock mould. Stubba is a separate part of Mocha that allows mocking and stubbing of methods on real (non-mock) classes. It works by moving the method of interest to one side, adding a new stubbed version of the method which delegates to a traditional mock object. You can use this mock object to set up stubbed return values or set up expectations of methods to be called. After the test completes the stubbed version of the method is removed and replaced by the original.

I’m thinking of ditching the name Stubba, because this part of the library is not solely concerned with stubbing. Let me know what you think.

Martin Fowler has a must-read article on why Mocks Aren’t Stubs.

Another great reference is JMocks documentation – in particular Yoga for your Unit Tests.

class ClassUnderTest
  def initialize(dependency)
    @dependency = dependency
  end
  def do_it
    @dependency.execute
  end
end

class Dependency
  def execute
    # complicated code
  end
end

Stubbing example

class MyTest < Test::Unit::TestCase
  class DependencyStub
    def execute
      true
    end
  end
  def test_stubbing_example
    dependency = DependencyStub.new
    class_under_test = ClassUnderTest.new(dependency)
    assert_equal true, class_under_test.do_it
  end
end

Mocking example

class MyTest < Test::Unit::TestCase
  class DependencyMock
    attr_reader :call_count
    def initialize
      @call_count = 0
    end
    def execute
      @call_count += 1
    end
  end
  def test_mocking_example
    dependency = DependencyMock.new
    class_under_test = ClassUnderTest.new(dependency)
    class_under_test.do_it
    assert_equal 1, dependency.call_count
  end
end

New Mocha Docs

James Mead — Sun, 03 Sep 2006 18:20:00 +0000

Spurred on by Thorsten’s comment on Gluttonous’ blog and a mention of Mocha in the Top 5 Rails Stories of the Week, I’ve given the Mocha documentation a major overhaul.

Now the RDoc only shows the public API which should hopefully improve the signal-to-noise ratio and show how simple it is to use.

I’ve also had a play with CodeRay and generated syntax-highlighted examples.

Good general information on mocking…

Injecting mocks (the Mocha way)

James Mead — Fri, 01 Sep 2006 06:26:00 +0000

I thought I’d compare and contrast the way Gluttonous was injecting mocks and how you can do it with Mocha.

Gluttonous’ way

  def test_process_exit
    delegate_methods_to_mock!(RailsFCGIHandler, :close_connection) do
      fcgi = flexmock()
      fcgi.should_receive(:close_connection)
      @handler.mock = fcgi
      @handler.stubs(:when_ready).returns(:exit)
      @handler.process!
    end
  end

Using Mocha

  def test_process_exit
    @handler.expects(:close_connection)
    @handler.stubs(:when_ready).returns(:exit)
    @handler.process!
  end

I think it’s a bit more readable and you don’t need the block construction which starts becoming a nuisance when you need to stub methods on multiple classes.

Mocks on Rails

James Mead — Thu, 31 Aug 2006 04:25:00 +0000

It’s great to see that Gluttonous has been playing with Mocha. Like many people, he’s found the ability to mock or stub class methods particularly useful – and this is one of the key differentiators between Mocha and other Ruby mocking libraries.

He’s been trying to improve the test coverage for Rails and submitted this patch where there is an interesting discussion¹ about why he would prefer to use Mocha. Interestingly, there has also been some recent discussion on the RSpec mailing list about adding Mocha-like functionality.

On a different note, in his article Mocks for Speed, Gluttonous draws attention to one of the advantages I have previously mentioned of using mocks extensively to write unit tests that test a class in isolation – namely a fast build.

¹ We have now released Mocha under the MIT license so it can be used for testing within Rails.

Mocha 0.3 released with Rails plugin

James Mead — Thu, 24 Aug 2006 17:59:00 +0000

A new version of the Mocha mocking and stubbing library developed at Reevoo has been released.

There is now a Ruby on Rails plugin which can be installed like this…

  $ script/plugin install svn://rubyforge.org/var/svn/mocha/trunk

Here are the release notes…

Rails plugin.
Auto-verify for all expectations, including those on concrete classes.
Include each expectation verification in the test result assertion count.
Filter out noise from assertion backtraces.
Point assertion backtrace to line where failing expectation was created.
New yields method for expectations.
Create stubs which stub all method calls.
Mocks now respond_to? expected methods.

Thanks for patches from Chris.

Enjoy!

Mocha 0.2 released

James Mead — Fri, 11 Aug 2006 11:57:00 +0000

I’ve just released a new version of the Ruby mocking and stubbing library, Mocha, that I first mentioned a while ago. Here are the release notes:

Small change to SetupAndTeardown#teardown_stubs suggested by Luke Redpath to allow use of Stubba with RSpec.
Reorganized directory structure and extracted addition of setup and teardown methods into SmartTestCase mini-library.
Addition of auto-verify for Mocha (but not Stubba). This means there is more significance in the choice of expects or stubs in that any expects on a mock will automatically get verified.

So instead of…

  wotsit = Mocha.new
  wotsit.expects(:thingummy).with(5).returns(10)
  doobrey = Doobrey.new(wotsit)
  doobrey.hoojamaflip
  wotsit.verify

you need to do…

  wotsit = mock()
  wotsit.expects(:thingummy).with(5).returns(10)
  doobrey = Doobrey.new(wotsit)
  doobrey.hoojamaflip
  # no need to verify

There are also shortcuts as follows…

instead of…

  wotsit = Mocha.new
  wotsit.expects(:thingummy).returns(10)
  wotsit.expects(:summat).returns(25)

you can have…

  wotsit = mock(:thingummy => 5, :summat => 25)

and instead of…

  wotsit = Mocha.new
  wotsit.stubs(:thingummy).returns(10)
  wotsit.stubs(:summat).returns(25)

you can have…

  wotsit = stub(:thingummy => 5, :summat => 25)

AutoMocha example

James Mead — Sun, 16 Jul 2006 19:01:00 +0000

Again – I’m not really very pleased with this example, but hopefully it makes some sense. It’s important to realise that the test is not running in a normal Rails environment with the standard auto-require. In fact the first time the Comment class is encountered AutoMocha uses const_missing to supply a Mocha::Mock in its place. From that point on – any further references get the same mock object.

  class Article

    attr_reader :id

    def accepted_comments
      Comment.find_all_by_article_id(self.id).select { |comment| comment.accepted? }
    end

  end

  require 'rubygems'
  require 'auto_mocha'
  require 'test/unit'

  class OrderTest < Test::Unit::TestCase

    include Mocha

    # illustrates stubbing of previously undefined class Comment
    def test_should_return_accepted_comments_for_this_article
      unaccepted_comment = Mock.new(:accepted? => false)
      accepted_comment = Mock.new(:accepted? => true)
      comments = [unaccepted_comment, accepted_comment]
      Comment.stubs(:find_all_by_article_id).returns(comments)
      article = Article.new
      assert_equal [accepted_comment], article.accepted_comments
    end

  end

Stubba example

James Mead — Sun, 16 Jul 2006 19:00:00 +0000

I don’t really like this example, but it’s the best I’ve got at the moment. The any_instance bit is particularly contrived, but hopefully you get the idea.

  class Order

    attr_accessor :shipped_on

    def total_cost
      line_items.inject(0) { |total, line_item| total + line_item.price } + shipping_cost
    end

    def total_weight
      line_items.inject(0) { |total, line_item| total + line_item.weight }
    end

    def shipping_cost
      total_weight * 5 + 10
    end

    class << self

      def find_all
        # Database.connection.execute('select * from orders...
      end

      def number_shipped_since(date)
        find_all.select { |order| order.shipped_on > date }.size
      end

      def unshipped_value
        find_all.inject(0) { |total, order| order.shipped_on ? total : total + order.total_cost }
      end

    end

  end

  require 'rubygems'
  require 'stubba'
  require 'test/unit'

  class OrderTest < Test::Unit::TestCase

    # illustrates stubbing instance method
    def test_should_calculate_shipping_cost_based_on_total_weight
      order = Order.new
      order.stubs(:total_weight).returns(10)
      assert_equal 60, order.shipping_cost
    end

    # illustrates stubbing class method
    def test_should_count_number_of_orders_shipped_after_specified_date
      now = Time.now; week_in_secs = 7 * 24 * 60 * 60
      order_1 = Order.new; order_1.shipped_on = now - 1 * week_in_secs
      order_2 = Order.new; order_2.shipped_on = now - 3 * week_in_secs
      Order.stubs(:find_all).returns([order_1, order_2])
      assert_equal 1, Order.number_shipped_since(now - 2 * week_in_secs)
    end

    # illustrates stubbing instance method for all instances of a class
    def test_should_calculate_value_of_unshipped_orders
      Order.stubs(:find_all).returns([Order.new, Order.new, Order.new])
      Order.any_instance.stubs(:shipped_on).returns(nil)
      Order.any_instance.stubs(:total_cost).returns(10)
      assert_equal 30, Order.unshipped_value
    end

  end

Mocha example

James Mead — Sun, 16 Jul 2006 18:59:00 +0000

I thought I’d put the examples from the RDoc README up here if only for the syntax highlighting.

  class Enterprise

    def initialize(dilithium)
      @dilithium = dilithium
    end

    def go(warp_factor)
      warp_factor.times { @dilithium.nuke(:anti_matter) }
    end

  end

  require 'rubygems'
  require 'mocha'
  require 'test/unit'

  class EnterpriseTest < Test::Unit::TestCase

    include Mocha

    def test_should_boldly_go
      dilithium = Mock.new
      dilithium.expects(:nuke).with(:anti_matter).at_least_once
      enterprise = Enterprise.new(dilithium)
      enterprise.go(2)
      dilithium.verify
    end

  end

Mocking and class interception

James Mead — Sun, 16 Jul 2006 17:51:00 +0000

While developing Mocha, I have to admit I’ve been somewhat remiss in keeping up-to-date with the latest developments on projects like RSpec and FlexMock. It looks like both projects have gone further than Mocha with implementing the JMock concepts. FlexMock also now supports simple class interception (see FlexMock::TestCase#intercept), but it admits to being “very simple-minded”, has “a number of restrictions” and “a proxy class constant will be left behind”.

I don’t think Stubba suffers from these limitations, but I’ll save a more detailed explanation for another post. It doesn’t look like either project has anything like AutoMocha.