+972 52-548-6969
The state of Rhino Mocks
time to read 1 min | 127 words
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
Don't you really use mocking anymore ?
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?
Onofrio, No, I don't really use them
Mohamed, I am not really using it, I am not really using mocks in general, actually.
Okay, so you don't use RhinoMocks anymore. But what techniques, frameworks do you use when testing nowadays?
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
Yeah, I will forget about the way better Moq-framework and work on the ancient and overly complicated Rhino Mock.
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.
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 ;)
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.
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.
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
RhinoMocks is Dead. Long life to NSubstitute
Comment preview