views:

624

answers:

8

TypeMock is too expensive for a hobbist like me :)

Moq or the next version of RhinoMocks have no plans on listening to the profiling API, why is that?

EDIT: This enables features such as:

  • Mocking non-virtual methods and properties (!).
  • Mocking browser environments.
  • simpler syntax which is less fragile (and not having to go trough mock objects).
  • Mocking static methods Sometimes is useful (Mostly in legacy scenarios, involving the dreaded DateTime.Now).
  • And more..
+3  A: 

If you are working on Open Source, you can get a free license of Typemock Isolator (but only for use with that).

TrueWill
Too poor to be working on O/S as well :) (just kidding). The question is out of curiosity.
gkdm
+2  A: 

Moq or the next version of RhinoMocks have no plans on listening to the profiling API, why is that?

Because it is very, very hard and requires a bit of C++ knowledge?

Ngu Soon Hui
Could you elaborate?
gkdm
Try and you'll find out - it's a not documented, very unforgiving API to work with
Dror Helper
@gkdm- have a look here- http://msdn.microsoft.com/en-us/magazine/cc188743.aspx
RichardOD
+1  A: 

Because TypeMock is only useful if you are testing code that was not written with testability in mind. There are a limited set of circumstances where this is useful and can generally be worked around.

In short, TypeMock is useful for programmers who:

  • don't have much experience with TDD and haven't figured out how to write code for testability
  • have a lot of legacy code lying around that need to have test fixtures strapped onto it

This makes this very valuable for those few people who need this feature, but for free software the cost vs. community benefit is very low.

Anderson Imes
I don't agree, i think non virtual methods have a place in systems built with TDD from the ground up. This is what bothers me the most, it affects my design considerably. Also TypeMock has a syntax with less ceremony which is important for unit-testing.
gkdm
There's no reason you can't use an interface to avoid having to use virtual methods. In terms of ceremony, I don't see how TypeMock is easier to use than, say, Moq.
Anderson Imes
Right - in case you do not use any 3rd party components and have a green field you do not need to use Typemock Isolator... or do you?
Dror Helper
I don't think so, no.
Anderson Imes
Do you think entities should have an interface (IInvoice)?
gkdm
I think if you need to mock an entity, your entities are not designed with the correct separation of concerns. There's no reason to mock an entity. If you do, it's not an entity.
Anderson Imes
TypeMock is useful, even if you built without testability in mind.
Judah Himango
Certainly, but if you are building for testability, the $800 - $1200 expense is harder to justify.
Anderson Imes
This argument is totally false, and it can de demonstrated to be so.For example, consider the "Template Method" design pattern (from the GoF book): it prescribes a base class (not an interface), where the "template method" should always be non-overridable (for reasons that should be obvious, I hope, if someone understands the pattern at all). And since you might need to mock such a method in a test for a client class, it follows logically that a good mocking tool must allow it to be mocked.
Rogerio
@Rogerio: Non overridable methods wouldn't be testable. I understand the pattern and why you would use it, but creating a base class in such a way as to not allow for the subclasses to be partially mocked isn't testable. It doesn't mean that the GoF book is wrong in any way... I've used this pattern myself quite a bit. I just make sure it's testable.If the isolation that having these methods non-overridable gives you you feel is particularly important to you, then maybe Isolator is the product for you (and I never said it was a bad product... it has its uses).
Anderson Imes
@Rogerio: there are plenty of other GoF patterns that would satisfy your requirements when using the Template Pattern, but also be testable. The Strategy Pattern comes to mind. It all comes down to if you are willing to design for testability (a point the top answerer on this question also makes).
Anderson Imes
@Anderson, the fact is that non-overridable methods ARE testable. This is my whole point. You don't need to sacrifice good design (such as a proper implementation of the Template Method) because of limitations in specific testing tools. My point is that this whole idea of "design for testability" is shaky (except when assuming that "testability" equals "maintainability" - in which case I agree).
Rogerio
@Rogerio: I think proper testability leads to maintainability and I have never felt I had to make sacrifices in design for it. It leads me to certain patterns over others, but the design is always sound. I might not choose the template method, but rather implement strategies. This isn't wrong, it's just a different approach to the same end. I choose to have explicit interfaces or contracts at touch points while others like yourself prefer a more OO/Is-A type of relationships with things. Neither are wrong, I just prefer mine and it happens to allow me to use free software.
Anderson Imes
@Rogerio: products like yours and Isolator have their place if you want ultimate flexibility.I've used and liked Isolator and even started with it, but when my tests were getting out of hand I stopped because I didn't find them very maintainable (which I think is what you were getting at). Ironically, Roy Osherove's book really got me over the hump on testing and I really feel like I understand it now and don't feel like I need that level of flexibility.I really do respect these products... it takes a lot of ingenuity to make them as usable as they are.
Anderson Imes
@Anderson, thanks for the nice comments. (BTW, JMockit is free and open source, in case there was any doubt.)I guess this all boils down to how each developer views design. The considerations which led me to create JMockit were, basically, that I wanted to preserve in the production code certain desirable (to me) design properties, but existing mocking tools would force me to give up on them. Apparently, some or all of those properties are not desirable to other developers. Who is right and who is wrong? We may never know, or maybe we are all right.
Rogerio
Lets all agree we are all wrong.
gkdm
@gkdm: This is generally the case with this business. I think that's why I like it so much. I feel like the comments here expanded on my original answer to make it make sense where my position comes from, so I'll let my answer stand. Even if it's not popular I still feel like it's a valid answer.
Anderson Imes
+5  A: 

TypeMock is too expensive for a hobbist like me

It's probably also too expensive to develop and release for free.

Jeff Hornby
+6  A: 

Declaimer I work at Typemock.

I'll try to answer your questions:

Is there any open source mocking framework resembling TypeMock?

There is no other mocking framework in .net that uses the profiler API.

Moq or the next version of RhinoMocks have no plans on listening to the profiling API, why is that?

I think it's a matter ideology. Ayende the creator Rhino mocks and Kzu the creator of moq believes in design for testability and that mocking framework should help you to achieve this design so they will not implement the features of Isolator even if it was easy.

TypeMock is too expensive for a hobbist like me

If you are working from home you can buy a cheaper personal license (I don't want to post a link to the Isolator buy page here but I'm sure you can find it.)

Hope it helps.

Ohad Horesh
I don't think it is a matter of ideology, but purely a technical difficulty. Ayende actually said he would accept a patch that adds support for mocking of static methods: http://ayende.com/Blog/archive/2008/05/20/Would-I-add-static-mocking-to-Rhino-Mocks.aspx
Rogerio
+1  A: 

Check out http://beanproxy.codeplex.com/ . It's a tool I've been developing for some time. It does not yet allow non-virtual proxies (aside from abstract and interfaces) and it doesn't support live objects (proxying live objects). However, it is free and open source. It super easy to use and it still being developed (there are plans to support non virtuals and live objects).

payo
How do you plan on achieving this?
gkdm
A: 

gkdm asked me how I plan on adding proxy support to http://beanproxy.codeplex.com/ for static and live objects, my answer is that I have no idea how. I studied a variety of ideas; none of which worked out. The closest solution I had was to create a profiling library, but this would require the tester to run my library as a profiler, and she wouldn't be able to just run my library with her tests. I spent days reading and testing ideas, nothing worked. I've given up that search but would be open to ideas again if anyone has any. Beanproxy is still a great tool that many fellow developers use. Use the issue and discussion tabs on codeplex if you have any specific needs or concerns about beanproxy. I'm always looking to improve it.

Well, with C# 5.0 they plan on opening the compiler for extensions, I think this will help. EDIT: Maybe they will also be so kind as to add a decent interception mechanism.
gkdm
+1  A: 

I understand this question is for the .NET world, but in case someone is wondering what exists in the Java world, I can say that the answer would be "yes, there is".

The JMockit toolkit is open source (MIT license), and unless I missed something, it's even more powerful than TypeMock. (Specifically, I don't see anything in TypeMock that would be equivalent to the functionality provided through the @Capturing annotation in JMockit.)

Rogerio