August 01, 2007 by alex
In this post I’d like to share some expirence we made while using mocha. But first a short introduction to mocha taken from the rubyforge page.
Mocha is a library for mocking and stubbing using a syntax like that of JMock, and SchMock. One of its main advantages is that it allows you to mock and stub methods on real (non-mock) classes and instances.
We started to use mocha on an existing test suite and changed our test code in place when we wrote a new test or had to update old ones. The transition was mostly painless, there were three things where we stumbled.
any_instance, we got some strange interactions with instances in other tests (Maybe changed with the 0.5 release, which is great btw.). You can get along very well without
any_instance by stubbing
.new. The second challenge was more the change in the way how to write tests. We were used to push all the required objects in the database, then run the code and examine the result afterwards.
This example shows an old functional test. As you can see we hit the database hard. We built some helper methods like create_user to create often used database objects, but we didn’t think about stubbing so far.
With mocha in place, we could test the expected behavior, which must be expressed beforehand. We also had to build new test helpers to provide us with stubs instead of full fledged objects, or at least real objects with stubbed behavior.
This code tests the same as the test above but this time with mocha. This test (almost) doesn’t hit the database and is more readable with the mocha syntax.
The last thing we had to learn. Every unexpected call to a mock object will cause your test to fail. This is good in a way, because you lessen the risk to miss some dependency in your code. But in the beginning it was hard to find the origin for the missed call, because the type is always ‘Mock’, so that you get errors like the following:
#<Mock:0x4cf5bf8>.find(:first, :order => 'created_at DESC'}) - expected calls: 0, actual calls: 1
Only the call parameters and the stack trace can reveal the culprit.
The reward for all the work are much faster running tests and a decoupled testsuite, because you can mock/stub dependencies.
Here some real figures.
Before: 424 unit tests with 637 assertions run in 319 seconds. 326 functional tests with 646 assertions run in 322 seconds
After: (still some potential) 659 unit tests with 1177 assertions run in 165 seconds. 574 functional tests with 1285 assertions run in 171 seconds.
The nubers speak for themselves 8)