Mocking frameworks – dream feature

Author Eli Lopian    Category .NET Tests, Product, TDD     Tags

imageThere are some developers SHOUTING, that mocking static and  non-virtual methods is a big No-No. Roy, is calling them dogmatic.

Come on guys, the most requested feature from Rhino.Mocks is the ability to mock non-virtual and static members, and Oren has even implemented these when possible (MarshalByRef Objects). I am sure that if it was easy, Daniel would do so too.

In other languages where objects can be swapped without Dependency Injection, there is no-one, calling these features – Bad Practice, just the opposite. They are called ‘Power features’, because that is what they are.

You might prefer to sweat and spend a lot of your time figuring out how to make your code testable, and you might find it easier in your company to introduce a free tool, but please, don’t call a tool that gives you lot of pain,  forces you to use DI (even if you don’t really need it) and to spend time creating utterly useless wrappers – a feature!

Bookmark and Share

14 Comments to “Mocking frameworks – dream feature”

  • Daniel Cazzulino May 20, 2008 at 5:54 am

    I guess you consider the new ASP.NET MVC interfaces for the HttpContext “useless wrappers” too.

    How are they different from what Pablo created? He’s just not Microsoft. Yet he did the exact same thing: abstract the statics behind interfaces and pass those around instead.

    Everyone seems to be missing the point here, which is: *Context.Current is BAD DESIGN. Microsoft is to blame in both examples I gave, not us, not TypeMock, not anyone else.

    Thankfully we’re seeing a change (i.e. ASP.NET MVC) with regards to testability first.

  • Eli Lopian May 20, 2008 at 9:10 am

    Not being able to mock non virtual methods is not a feature created on purpose. I am sure that if you could overcome this flaw you would.

    Typemock helps teams become agile, it helps them tests there code that using other frameworks is too difficult. It helps teams that have well though our designs, test their code, it helps teams refactor their code base to the best design they can think of.

    About your question, ASP.NET MVC is more than just a whim to make it easier to test ASP application using free tools.
    It is an Microsoft’s answer to RoR, that has been seen as a rapid way to write web applications. As Scott Hanselman says: It is targeted at 5% of the developers, the other 95% should still use the normal ASP.NET.

  • Joe May 20, 2008 at 11:16 am

    You make TypeMock free or open source and you’ll see how fast all these opposed will embrace it. ALT.NET has become more of a freebie thing than a alternative and best practices..

  • Unit Tests for WCF (and Moq) Part II - Pablo M. Cibraro (aka Cibrax) May 20, 2008 at 8:30 pm

    [...] Unit Tests for WCF (and Moq) Part II   My latest post about “creating wrapper classes” for mocking the WCF context has started generating some controversies. I initially wrote those classes to decouple my service implementation from the concrete implementation of the WCF context,  something that  did not have anything to do with the static nature of the context. (I can still pass the current instance as an argument to my service implementation). As I mentioned in my previous post, the WCF context is neither a base class (with virtual methods) nor an interface, so it can not easily mocked, that is main issue here. I am not sure if TypeMock allows mocking this kind of class as well, probably yes, I have never used that tool before so I do not know.  It would be great to have a natural or easy support in C# for mocking non-virtual methods or statics, but it is not there now. I personally prefer writing some simple wrapper classes or “utterly useless wrappers” as someone call them  (In fact, it only took me 5 minutes to write them, and I do not think my productive was affected by that) rather than creating code that can only be tested by an specific tool. I am not saying that you should not use TypeMock, anyone is free to use the tool that works best for his needs. Published 20 May 2008 02:28 PM by cibrax Filed under: WCF, Moq [...]

  • Daniel Cazzulino May 21, 2008 at 12:41 am

    I referred to ASP.NET MVC technique for allowing HttpContext to be mockeable. I know what it’s for and its larger role, but that has nothing to do with my point.

    The problem is that Microsoft has imposed to all of us to think that private/internal/non-virtual by default is a good thing. In Java it’s the exact opposite, and nobody’s complaining. Why do you consider something that is the standard in Java to be such a bad thing to do in .NET?

    Just try to remember the COUNTLESS times you’ve been THIS close to getting a particular .NET Framework class to behave just like you wanted, only to find some internal/sealed/non-virtual dead end.

    For that very reason, I don’t like at all statics, non-virtuals, and internals. Not only they are hard to test, they make code SO much harder to make extensible!

    I have added more to the point on my post ( Basically, I’m not dying for TypeMock features even if they were free or trivial to implement.

    It boils down to framework-imposed guidelines, rather than “teach&pray” guidance. RoR also imposes its own way of doing things in RESTful web services, for example. You have to fight it quite hard to do what DHH didn’t think was a good idea. And that’s a GOOD thing IMO.

  • naraga May 22, 2008 at 9:31 pm

    I think community will stop pointing at TypeMock as evil tool once you stop using argument with overengineering and agility.
    There are patterns and there are principles. Overusing or missusing of pattern can lead to overengineering while principles (and you can find bunch of them in for example Larman’s book) are design guidelines which you should follow ALWAYS! Decoupling and separation of concerns are just two of them.
    I can certainly think of situations where using your tool would be helpfull but theese are really rare cases and to me not worth buying a tool.
    At the end i will give you an controversial example. Do you think that for example by encouraging developers to use typed datasets or mix UI with logic you are supporting agility?
    For many developers guidence is much more important than allowing them to hack into “static” even if they dont know this.
    So i would finish by recommending you not to use purity arguments in community that eternally struggles for pureness and is very strong opinioned about it.

  • Eli Lopian May 22, 2008 at 9:51 pm

    I guess that this tool is not for you naraga (Have you even tried it?)

    There are many developers who understand typemock-Isolators power and find that it enables them to become – more agile and to write better code at faster speed. Giving their company a competitive edge…

  • naraga May 22, 2008 at 10:42 pm

    Yes Eli i did. It is really nice piece of software. But my point was that for company is more important (and thus competitive advantage) to have developers with good design skills than to have tool that allows them to write poor code. I believe that your tool is technically briliant but power that it provides is unnecesarry for me.
    There are many alternatives that are free and offer almost the samePlease could you give me an example where your tool leads to both better design and demonstrates feature that is not available in other tool?

  • Eli Lopian May 22, 2008 at 11:14 pm


    It might be better to have both talented developers (good design skills), and tools that allows then to have Ruby like/AOP capabilities in .NET.
    You can then, test GUI, Web Services, multi-threaded applications and can handle a diversity of designs. That can/might lead to leaner design.

    Of course you may not see this as a better design, and that is your prerogative. If so, stay with the alternatives.

  • Brian Johnston August 28, 2008 at 5:29 pm

    I know I’m several months late on this; but it really caught my eye.

    Eli and Joe have it spot on.

    It’s idealogical and a little too much hero worship to want everything to be service-locater/DI/IoC. Many companies have IT shops that hire developers of all experiences levels and truthfully aren’t concerned with how the software is written, just that it works – and they have no desire to be educated on what’s YOU think is best. To think that a developer who wants to build software ‘right’ has any say-so in who he or she works with is totally naive.

    Also this whole private/static/virtual stuff? Come on now; that’s just plain stupid. Who in there right mind is going to make a private method public for testing? It’s private for a reason! Ditto for static and virtual. That’s a matter of opinion and developer preference. You don’t want someone coming along using that method for a reason, or you want them to make an implementation for a reason, or it’s static for a reason. So yeah – some leftists will say that if you have private, static, or virtual methods you’re designing something wrong, but ‘right’ is subjective and open to interpretation – what’s right for you may not be right for someone else. Wonder if it’s so wrong why Fowler has so many patterns that rely on inheritance, virtual methods, and static classes?

    And all these extra classes and interface to decouple? Ok – it took you 5 minutes to create? How long will it take someone to understand all those extra moving parts in 2 years when you’re not around? How much longer will additions and changes take after your not around because now they have to make these changes in both the original class and the interface(s)? Check out this on NHibernate – what a mess: – and what’s funny there is that this is the framework a lot of the people promoting loose coupling use! 60 some odd namespaces, most everything has a dependency on something else, the tests won’t run without a database installed – what a fricken mess! These same people also are usually the ones who think MSTest sucks (even though I use it every day and it will be a cold day you know where when I go back to NUnit), think Entity Framework sucks, and Microsoft in general sucks. They’re people who generally have a chip on their shoulders and only work on green-field data applications and are one trick pony. Put them on a large legacy brown-field application or something non-web or non-data, or any of these in a corporate or better yet military, IT shop, and there world falls apart around them. This is evidenced by the weak argument that only explores the ‘create’ side and doesn’t explore somebody else extending or maintaining or dealing with it 2 years down the road.

    And the Java comment: If Java was so great then why have so many switched to .NET from Java? If you think it’s so much better…go back to it – I won’t miss you. There’s umpteen million languages out there for a reason. They’re all different, they all take different twists on things and none are perfect and all are usable and written just right to someone/some business/somewhere. Get off your high horse already!

    An experienced developer has many tools in there their box and doesn’t see everything as nails. They realize that while DI/IoC/SL is good at job A, the staff and circumstances at job B might require a traditional 5 tier system that is heavy on process, and at job C might require a BO framework such as CSLA, and at job D might require using a functional programming language such as Python.

    Sorry for the rant, but this is a damn good product and anyone who can’t see that is truly inexperienced amd/or naive.

  • RogĂ©rio Liesenfeld October 6, 2009 at 8:42 pm

    Well said, Brian (yeah, I know this is one year late).

    Personally, I am sick and tired of hearing those claims that “designing for testability” is all for the good. Then, when you actually look at a real project, what you typically see is a huge mess, with lots of pointless interfaces, thousands of lines of code for “object wiring”, and so on. If you examine the motivations for that, you find that people just wanted to add some new IoC framework to their resume, or were trying to impress others be showing off how many different patterns and frameworks they could apply. They hardly care about the poor sap that is going to maintain it years later.

  • magallanes October 28, 2009 at 5:09 pm

    Hi there:

    I was investigation about all this matter and i am found that:
    -some (if not all) extra stuff will not increase the productivity instead is a burden. Let’s say, usually a PHP developer is more efficient than a .NET and a .NET is more efficient than a Java dev. In fact, adding hibernate to java will become even less efficient.

    And btw :UNIT TEST is a joke, just get rid of them.

  • A practical example on how to mock static classes without TypeMock – Clarius Consulting Blogs February 25, 2011 at 2:15 am

    [...] used the ASP.NET MVC team, I don’t hear anyone calling HttpContextBase and friends “utterly useless wrappers“. I find it hard to think about a case where such a technique could not be applied to make [...]

  • A practical example on how to mock static classes without TypeMock – Daniel Cazzulino's Blog February 25, 2011 at 4:48 am

    [...] used the ASP.NET MVC team, I don’t hear anyone calling HttpContextBase and friends “utterly useless wrappers“. I find it hard to think about a case where such a technique could not be applied to make [...]

Post comment