There 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!
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.
Daniel,
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.
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..
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 (http://www.clariusconsulting.net/blogs/kzu/archive/2008/05/18/mock_statics_without_typemock.aspx). 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.
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.
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…
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?
Thanks…
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.
http://www.elilopian.com/2008/04/29/understanding-mock-objects-better-design/
Of course you may not see this as a better design, and that is your prerogative. If so, stay with the alternatives.
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: http://codebetter.com/blogs/patricksmacchia/archive/2008/08/26/nhibernate-2-0-changes-overview.aspx – 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.
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.
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.
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.