Ayende @ Rahien

It's a girl

The state of Rhino Mocks

I was asked to comment on the current state of Rhino Mocks. The current codebase is located here: https://github.com/hibernating-rhinos/rhino-mocks

The last commit was 2 years ago. And I am no longer actively / passively monitoring the mailing list.

From my perspective, Rhino Mocks is done. Done in the sense that I don’t have any interest in extending it, done in the sense that I don’t really use mocking any longer.

If there is anyone in the community that wants to steps in and take charge as the Rhino Mocks project leader, I would love that. Failing that, the code it there, it works quite nicely, but that is all I am going to be doing with this for the time being and the foreseeable future.

Comments

Mohamed Meligy
03/30/2013 03:18 AM by
Mohamed Meligy

Of course using a library is different from having to support all requests from all over the internet...

But still, Onofrio's comment raises is inspiring. Are you still using Rhino Mocks in your projects or something else? Or are you just finding very rare need to use a mocking framework at all?

Ayende Rahien
03/30/2013 09:19 AM by
Ayende Rahien

Onofrio, No, I don't really use them

Ayende Rahien
03/30/2013 09:20 AM by
Ayende Rahien

Mohamed, I am not really using it, I am not really using mocks in general, actually.

Ruud
04/02/2013 12:01 PM by
Ruud

Okay, so you don't use RhinoMocks anymore. But what techniques, frameworks do you use when testing nowadays?

Ayende Rahien
04/02/2013 12:02 PM by
Ayende Rahien

Rhud, I generally use stuff that allows in memory operation, like RavenDB. Or I replace the infrastructure as a whole, see my posts about testing commands. http://ayende.com/blog/154273/limit-your-abstractions-and-how-do-you-handle-testing

Ben T
05/08/2013 10:08 PM by
Ben T

Yeah, I will forget about the way better Moq-framework and work on the ancient and overly complicated Rhino Mock.

Judah Gabriel Himango
05/09/2013 12:33 AM by
Judah Gabriel Himango

I must admit, when Oren told me last year that he doesn't really believe in mocking anymore, my jaw hit the floor.

But more and more, I find myself in agreement; mocking tends to produce brittle tests that are tied to implementation details. Integration tests with real components may run slower than unit tests with mocks, but they tend to be an actual test of the system.

Alessandro Riolo
05/09/2013 01:42 PM by
Alessandro Riolo

This feel like a vindication :) Almost 7 years ago I had a huge spat with a colleague also on those points, the chap managed to convince our boss, and at the first culling I had to look for a new job (actually another reason was that I was supporting off shoring some work to H.Verissimo's then newly founded consultancy, while the other guy won the argument for another team). At the time I remember being thrown at some heavy post written by Oren. Anyway, no bad blood on that, I ended up finding a better job, with more like minded people, albeit too quite infected by the mocking disease. Funnily enough, nowadays I may well be far more condescing on mocking than then ;)

Ayende Rahien
05/10/2013 05:57 AM by
Ayende Rahien

Joshua, Mocks are something that I would generally use nowadays only for external components. Stuff that is entirely out of my control. I would mock the CreditCard company service, for example. For internal stuff, I don't do that. Testing object interaction independently from the system only means that you are setting in stone those interactions. If you need to change them in some way, that is going to come back and bite you later on. Consider a scenario in which we change the implementation to increase performance, without changing observable behavior. With mocks, tests will usually break because of that.

This isn't enabling change, this is shackling it with iron chains.

Darren Cauthon
05/12/2013 06:12 PM by
Darren Cauthon

The butcher says, "Nothing's better than a well-cooked steak. I only eat meat!"

The gardner says, "Fresh vegetables are great, I only eat veggies!"

Their customers use food from both to make well-balanced meals.

The testing that Ayende is talking about is integration testing, and he's right. Testing your entire system allows you to components while verifying that the end behaviors do not change, and focusing only on individual object interactions without the context in which they are meant to be run will bite you. And of course, you'll have to use mocking in the integration tests for external systems like credit cards (unless you happen to provide your CI test runners with a stolen credit card, an expired credit card, an over-the-limit card, etc etc.).

Does that mean you should give up unit testing? I hope not. Integration tests are great at the "blog post" level of complexity, but details abound in production systems. Trying to create such wide-ranged integration tests is pretty difficult for every detail. It's much easier to cover those specific details with unit tests.

I think the balanced method is to use both -- integration details for the more obvious user stories, with unit testing driving the details. You'll get the benefits of both approaches. The problem I see in this specific case is that the "limited abstraction" approach makes unit testing very difficult, if not impossible -- forcing the developer's hand into integration tests.

What's interesting to me about Rhino Mocks (and other libraries) is how the general philosophy and ideas behind the author(s) seep in. It's been a while since I used Rhino Mocks, but it doesn't surprise me that the author has moved on from mocking.

meisinger
05/13/2013 04:49 AM by
meisinger

i completely understand the lack of inactivity but am a little surprised over the lack of interest

i will be more than happy to help out in any way i have been using Rhino Mocks for so many years... it would be a shame to lose it

Ari
05/16/2013 09:14 PM by
Ari

RhinoMocks is Dead. Long life to NSubstitute

Comments have been closed on this topic.