+972 52-548-6969
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.
Comments
Or you can use Delegates and don't add any functionality to RhinoMocks. See my post about it
http://seermindflow.blogspot.com/2008/05/how-to-test-static-method-call-in-c.html
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 ?
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.
An alternative is to use the Duck Typing project mentioned by Phil Haack in this post:
http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx
and used in this one:
http://haacked.com/archive/2007/09/09/ihttpcontext-and-other-interfaces-for-your-duck-typing-benefit.aspx
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.
Cheers
Matt
Comment preview