One of the steps in my
15 TDD steps to create a Rails application article was using the mocking technique.
Mock objects were used in a test for a controller method. From the feedback I received I noticed that this technique is not very popular and requires a more detailed explanation. This article describes why you might want to use mock objects for testing your controllers and how it simplifies the testing setup and code. The mocking library I use in this article is
Mocha.
Rails controllersBefore I go into details about testing Rails controllers, let's clarify what is the responsibility of a Rails controller.
Ideally, a controller method should only call one method on a model class. Sometimes the method on the model that we call is some kind of finder like Person.find(:all). The result of the method should then be passed to the view.
A Rails controller should be a thin layer between your model classes and the view part.
A sample implementation looks like that:
def learn
@word = Word.random
end
As we see, we call the 'random method on the Word class which represents some model part of our application. Then we pass the result to the view via @word.
Testing Rails controllersBeing aware of that, we know what we want to test:
A learn method should:
- call the Word.random method
- pass the result to the view
Problems with traditional approach to testing Rails controllersNow, what if we simply construct the test like this:
def test_learn_passes_a_random_word
get 'learn'
assert_kind_of Word, assigns('word')
end
The first problem here is that it calls the Word.random method, thus
accesses the (test) database. It means we need to have some fixtures loaded so that the random method can retrieve some word from it.
The second problem is that we only test the type (kind_of) of the object assigned to @word. It means
we don't fully test the method. We could imagine an implementation of the learn method that passes the tests but does the wrong thing (by assigning any other object to @word). Not ideal.
Testing with mock objectsFortunately, we can use mock objects here and solve both problems.
We will replace the Word.random method with a method that always returns an object that we prepared before. Another advantage is that:
We don't connect to the database from our unit tests which is A Good Thing.
The object that we prepare before can then be used to assert whether the one passed to the view was the same as the result of calling Word.random method.
random_word = Word.new
Word.expects(:random).returns(random_word)
As we see, we prepare a random_word object, which is simply a new instance of a Word class. The next line does two things:
- expects(:random) - sets our expectation that the random method will be called
- returns(random_word) - replaces the real implementation of the 'random' method with an implementation that always returns the random_word object.
Btw, we didn't have to create a new instance of Word here. We could have used Object() there and that would work fine. The crucial part is that we compare the objects we return from Word.random with the one assigned to @word.
What is an expectation?An expectation is almost like an assertion. The difference is that we set it
before the actual call to the method that we test. The test will fail if the expectation isn't met.
We now extend the test with a call to the 'learn' method that we test:
random_word = Word.new
Word.expects(:random).returns(random_word)
get 'learn'
This test should now pass with the following implementation:
def learn
@word = Word.random
end
We also want to test that the object was assigned to @word, so we need an additional line with assertion:
def test_learn_passes_a_random_word
random_word = Word.new
Word.expects(:random).returns(random_word)
get 'learn'
assert_equal random_word, assigns('word')
end
The assertion tests the equality of the random_word object and the @word (we access it using assigns('word')). It's possible only thanks to the fact that we replaced the real Word.random method and have a reference to the result of this method.
Benefits
- not connecting to a database
- no need for preparing fixtures
- faster tests
- controller tests are less fragile for model changes
Drawbacks
- some developers may find the tests less readable
- if you rename the model method, the controller tests will still pass
- increased need for some integration tests - Selenium or standard Rails integration tests
ConclusionI hope that this article sheds more light on what are mock objects. I strongly recommend trying to add some tests like that to your test suite. If you want to read more about mocking you should first go to
the classic Martin Fowler's article on Mock Objects. After that go to the
Jay Field's blog. You can also find some interesting examples on
the Mocha website.
