Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,131 | Comments: 45,568

filter by tags archive

Would I add static mocking to Rhino Mocks?

time to read 1 min | 156 words

Eli Lopian joined the discussion about Mocks, Statics and the automatic rejection some people have of Type Mock and its capabilities.

Here is the deal.

  • I don't like the idea of mocking statics.
  • Given a patch that would add this capability to Rhino Mocks *, I would apply it in a heartbeat.

Hm... that seems inconsistent of me...

Leaving aside the fact that I feel no urging need to be internally consistent, I don't have an issue with the feature itself. Mocking statics is not inherently bad. What I consider bad is the reliance of such a feature to write highly coupled code.

It is more an issue of guidance and form than a matter of actual features.

* Note that I said, "given a patch", the feature is not actually interesting enough for me to spend time implementing it.



Or you can use Delegates and don't add any functionality to RhinoMocks. See my post about it


Ayende Rahien

This is still just adding a layer of indirection


Which allows you to test statics in an easy way.

"layer of indirection" - Is this not what Dependency Injection is for ?

Steve Bohlen

I don't find your two positions so much inconsisntent as non-dogmatic :)

It rather seems to me that so long as the feature being offered as a patch to RhinoMocks is about Mocking :D there should be little debate about its inclusion (so long as its good code, offers something others need/want, and doesn't introduce 'breaking changes' that would discourage others).

This feature seems to me a logical addition to the library; its really in the same vein as the 'I hate typemock' debate that always flares because typemock supports testing 'bad designs'.

To me, that entire line of thought is a complete non-sequitor; Visual Studio supports my dragging datatables from the server explorer into the dataset designer to create an 'instant' data-access-layer' thru a bunch of wizards -- there isn't a developer worth his salt (outside of Redmond perhaps) that thinks this is a good feature to use, but its inclusion in VS doesn't make me decide 'VS is evil, I won't use any of it'.

Instead, I wisely stay away from that feature since using it is going to cause me (significant) future pain in my work. Tools almost always contain aspects that one or more users will consider to be 'bad' or otherwise to be avoided but its a logical fallacy to assume that the mere presence of a feature in a tool means that I have to use it all the time...sometimes that feature is there so that the one time out of 100 that I truely DO need it, its there for me.

Nothing inconsistent about your position at all from my perspective.

Matt Ellis

An alternative is to use the Duck Typing project mentioned by Phil Haack in this post:


and used in this one:


More a way of restructuring your code to avoid the tight coupling to static classes than to be able to test these static classes, admittedly, but distribution (or even just support) from a mocking framework would certainly raise its visibility.



Comment preview

Comments have been closed on this topic.


  1. RavenDB Conference 2016–Slides - 2 hours from now
  2. Proposed solution to the low level interview question - about one day from now

There are posts all the way to Jun 02, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats