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.
- James Mead, An Introduction To Mock Objects In Ruby, extracted from a presentation in the London Ruby Group.
- Mathew Williams, How I Learned to Stop Worrying And Love Web Application Testing.
- Bruce Tate, Mocking And Stubbing in Ruby On Rails. The example that Bruce uses to illustrate the difference between mocking and stubbing could be clearer, in my opinion.
- Ned Wolpert, Ruby Mocha.