Skip to main content

Mocha Internals under Scrutiny

I’ve just read Brian Guthrie’s recent article entitled Ioke mocking, Mocha as exemplar. Brian has volunteered to work on a mocking framework for Ola Bini’s Ioke. I’ve read bits and pieces on Ola’s blog about the development of Ioke, so I was very interested to see what Brian had to say. He makes some very valid comments; both about mocking in general and about the internals of Mocha.

Mocking in General

I agree with him about it being so easy to stub in prototype-based languages, but (as he says) mocking libraries offer more than just stubbing. One related problem is that different people mean different things when they talk about “mocking”. xUnit Test Patterns by Gerard Meszaros provides a useful breakdown of the different capabilities offered by different types of what he (more generically) calls Test Doubles :-

  • Dummy Object
  • Test Stub
  • Test Spy
  • Mock Object
  • Fake Object

In my LRUG presentation: An Introduction to Mock Objects in Ruby, I translated these different types of Test Doubles into Ruby examples which people might find helpful.

Mocha Internals

I’m glad that Brian drew some inspiration from reading the Mocha source code – I have to admit I went through a similar exercise with the jMock source code some time ago. So thanks to Nat & Steve for that.

Mocha (particularly the internals) has changed a lot since the early releases but, as Brian mentions, the original split between the so-called Mocha and Stubba components has not really been bridged internally. Reading this critique has just helped me realise that a mock object in Ruby is, after all, just an instance of a BlankSlate-like object and could therefore be approached with Stubba-like tactics (rather than the specialised Mocha-like tactics which are currently used). I think this could lead to a significant simplification of the code. Yay! I love open source :-)

As well as the welcome critique, Brian made some very pleasing comments :-

I’d happily recommend [Mocha] to others as a good example of how to pull off some hairy Ruby functionality without writing a whole lot of hairy Ruby code in the process.

Much of Mocha is like that: moderately sized, neither opaque in its density or transparent in its verbosity. Nice, I suppose, for my own definition of nice.

Reflections

I’m a fan of the Pragmatic Programmers suggestion to “learn a new programming language every year”. As an extension to this, I think there is some truth in what I think is a quote from Dan North : “everyone should write a mocking framework”. In any case, I certainly know that one of the most important things I’ve got out of writing Mocha is a deeper understanding of Ruby internals.

Lastly this seems like an opportune time to thank my former colleagues at Reevoo: Paul Battley, Chris Roos and especially Ben Griffiths for all their help and encouragement with Mocha.