Mocks and stubs in Ruby on Rails. The Mocha solution.

November 26, 2007

 

We know that we want our tests to be repeatable, simple and fast. Fast is the key word here. Some tests involve tasks that we don’t want to be run because they involve high time consumption. A classic example is trying to avoid the connection to the database when is not neccessary. This testing approach has lead to a whole framework called UnitRecord that allows us to test ActiveRecord models without hitting the database. This nicely wrapped gem makes use of stubs for faking database columns. But no so fast; let’s explain before what are stubs and mocks.

First of all should we point the difference (huge difference) between mocking and stubbing, as some times is not well understood. Stubs and mocks are similar concepts that drive to completely different testing philosophies, the classic TDD (Test Driven Development) and the fairly new BDD (Behaviour Driven Development).

On one hand, we would want to test our classes and methods by the results they give to us. If we have a method that takes an array of integers and returns it in ascendant order, we should consider writing a test which will take the array [4,3,5] and check that the result will be [3,4,5]. We don’t care about how our software do that, we care about whether what our software is giving as a result. This is classic TDD.On the other hand, we know that there are different algorithms for sorting an array. Maybe we were using an easy insertion sort algorithm, then we realised that the sets of numbers were getting bigger and bigger and decided to switch to a quick sort. The method is the same, the result as well, the way it does it is different. Testing our software paying attention at how it does it (and thus giving to the test cases our expectations on what the software is going to do in order to solve the task) is BDD.

A still-awake reader would have noticed that BBD involves highly coupled tests. A mock will have our expectations on the behaviour of the method declared, and our expectations will change every time we change the internal algorithm of our method. This is, I think, the biggest drawback of BDD and mocks. It has many advantages though, especially about the need to think about the design of our software from the very begging, when we are writing our test (yes, before start coding the real app), if you name correctly your tests cases, of course. BDD promotes also some good design techniques and autocomments the implementation code on the test (as we are describing there how our code works). Martin Fowler has an excellent article comparing advantages and disadvantages of both approaches, with some examples written in Java. And if you decide to go BDD, you should check RSpec for Ruby.If you still have to decide, we have in Ruby a marvellous tool that allows us to stub and mock with one single framework, called Mocha. RoR developers coming from Java will be happy as the syntax of Ruby Mocha is intended to be as close as possible to JMock. Here it is a brief test example of mocking:

def test_should_start_engine
	engine=mock('engine')
	car=Car.new(engine)
	engine.expects(:start)
	car.start
end

And an example of stubbing with Mocha:

def test_should_return_false_for_failed_print
	document = stub("my document")
	document.stubs(:print).returns(false)
	ui = View.new(document)
	assert_equal false, ui.print
end

Notice how in the first case we declare our expectations, while in the second case the assert the result of the test (this phase is called verification). We don’t have verification phase in BDD, thus we don’t have assertions.

Further reading

About these ads

One Response to “Mocks and stubs in Ruby on Rails. The Mocha solution.”

  1. monde said

    Mocha is so awesome, especially when you are testing code that is relying on other library calls. For example if you have code that is loading a YAML file but you don’t really want it loaded in the testing environment. This will ensure that its loading is called and some testing value is returned.

    YAML.expects(:load_file).once.with(‘/tmp/some.yml).returns({:foo=>:bar})

    Another example, making sure a call that goes out over the wire is trapped with some dummy return data.

    Net::HTTP.expects(:get).with(“www.google.com”, “/”).returns(“hello”)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: