Testing: Mocha's stub_everything method

The Mocha mocking framework provides a method, stub_everything, that returns an object that will respond 'nil' to any message sent to it. The stub_everything method is indispensable for creating an object that is needed for testing, but the interactions are completely unimportant.

For example, in the following test the ReservationService::reserve_for method needs to return a duck that responds to the same methods that are defined on the (not shown) Reservation class. However, the focus of the test has nothing to do with the behavior of the reservation duck, so stub_everything is the perfect duck because it requires no additional set up and responds to all the methods required without error.

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

class ReservationService
  # implementation
end
class MaidService
  # implementation
end
class VipService
  # implementation
end

class HotelRoom
  def book_for(customer)
    reservation = ReservationService.reserve_for(customer, self)
    MaidService.notify(reservation) if reservation.tomorrow?
    VipService.notify(reservation) if reservation.for_vip?
    reservation.confirmation_number
  end
end

class HotelRoomTests < Test::Unit::TestCase
  def test_book_for_reserves_via_ReservationService
    room = HotelRoom.new
    ReservationService.expects(:reserve_for).with(:customer, room).returns(stub_everything)
    room.book_for(:customer)
  end
end

The stub_everything method is also nice because it can take parameters. For example you may want to test that the book_for method returns a confirmation number. The following test specifies the value of the confirmation_number value, but it uses stub_everything so that each other method call will return nil (without causing an error).

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

class ReservationService
  # implementation
end
class MaidService
  # implementation
end
class VipService
  # implementation
end

class HotelRoom
  def book_for(customer)
    reservation = ReservationService.reserve_for(customer, self)
    MaidService.notify(reservation) if reservation.tomorrow?
    VipService.notify(reservation) if reservation.for_vip?
    reservation.confirmation_number
  end
end

class HotelRoomTests < Test::Unit::TestCase
  def test_book_for_reserves_via_ReservationService
    reservation = stub_everything(:confirmation_number => "confirmation number")
    ReservationService.stubs(:reserve_for).returns(reservation)
    assert_equal "confirmation number", HotelRoom.new.book_for(:customer)
  end
end

Another usage of stub_everything that might not be immediately apparent is that it can be used as both a stub and a mock. The following test creates a stub and then sets an expectation on it. As a result, the expectation is verified (which is the focus of the test) and all other calls to the same object simply do nothing.

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


class HotelTests < Test::Unit::TestCase
  def test_name_is_set_from_options
    hotel = stub_everything
    hotel.expects(:name=).with "Marriott"
    Hotel.stubs(:new).returns hotel
    Hotel.parse("Marriott||")
  end
end

class Hotel
  def self.parse(attributes)
    hotel = self.new
    hotel.name, hotel.location, hotel.capacity = attributes.split("|")
    hotel
  end
end

Using the stub_everything method of mocha can remove noise from tests and also make them more robust by ignoring all messages that are unimportant to the current test.

Ruby: Mocks and Stubs using Mocha

Update: Older versions of Mocha didn't warn when a stub was never called. The newer versions will; therefore, it makes more sense to prefer stub since it's less fragile and more intention revealing. I no longer feel as I did when I wrote this entry, but I've left it for historical reasons. Related reading here.

I've previously written about using Mocks and Stubs convey intent. When I was using C#, I believed this was the best solution for creating robust tests. These days, all my code is written in Ruby. Making the switch to Ruby provided another example that reinforces an assertion I've heard before: Best Practices are so context dependent it's dangerous to use the term.

Here's the reason I no longer feel as I did when I created the above entry: When using Mocha to mock or stub behavior, I can't think of a reason I would ever want to use SomeObject.stubs(..) instead of SomeObject.expects(..). The closest I could come to a reason was that stubs will allow an arbitrary number of calls to the same method. However, I don't believe that's a good enough reason since I can also use SomeObject.expects(:a_method).at_least_once.

The problem with using SomeObject.stubs is that it's almost the same as using SomeObject.expects, except if it's no longer necessary it doesn't cause a test to fail. This can lead to tests that unnecessarily stub methods as the application's implementation changes. And, the more methods that require stubbing the less the test can concisely convey intent.

I'm not asserting that you should never use SomeObject.stubs, but I do believe it's smarter to favor SomeObject.expects if you are concerned with keeping your test suite well maintained.

Of course, none of this is related to creating actual stubs for your tests. I still believe it's wise to create stub object instances for classes that are required for a unit test, but are not the class under test. For example, if I were testing a mapper class, I would use a stub for the objecting being mapped.

test "an order's id is mapped to the request object" do
  request = OrderServiceMapper.create_request(stub(:id=>1, ...))
  assert_equal 1, request.order_id
end

I use a stub in the above example because I don't want to couple the test to the implementation of an order. I believe this creates a more robust, maintainable test

Should Rails include Mocha?

I like the way the Rails integration tests currently depend on Mocha.

# integration_test.rb
...
begin # rescue LoadError
require 'mocha'
...
rescue LoadError
  $stderr.puts "Skipping integration tests. `gem install mocha` and try again."
end

In fact, I stole the idea and changed it up a bit for sqldsl.

unless File.directory? File.dirname(__FILE__) + '/../vendor/mocha-0.4.0/'
  raise "mocha 4.0 is required to run the test suite. create the 'vendor' directory as
         a sibling of test and 'gem unpack mocha' in 'vendor'"
end
$:.unshift File.dirname(__FILE__) + '/../vendor/mocha-0.4.0/lib/'
require File.dirname(__FILE__) + '/../vendor/mocha-0.4.0/lib/mocha'

However, now I'm wondering if Rails should depend on, and include Mocha.

I've previously written that I think xUnit frameworks should include Mocks. Since Rails bakes in testing, I believe it should provide you with the full array of testing tools, including Mocks.

Thoughts?