Is there any open source mocking framework resembling TypeMock? [closed]
Asked Answered
K

8

19

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..
Kellum answered 7/10, 2009 at 20:51 Comment(8)
please express what you need... otherwise it's not a real questionPrinz
I gotta say this question is worded like an advertisement rather than a question. I will answer with why TypeMock is very likely overkill to counteract this.Research
This doesn't seem like an advert to me, sounds like someone looking for an OSS alternative to a paid product. If it is an advert, it's possibly the worst one I've ever seen, basically saying "this product costs too much!"Opossum
The "And more.." with a link to Isolator's website right below a list of TypeMock's (admittedly unique) features? It looks like an advert... sorry if you disagree.Research
TypeMock is priced absurdly (800$ - 1,200$ per developer!).Kellum
@anderson-imes we don't advertise like this. As @Kellum said it's lame as an advertisement. Look how many people saw this question: ~130 there are probably better ways to advertise and get to more people.Opiate
@ohad: just saying it looked like an advertisement, not that it was a good one. I like your product (I recommended its purchase to my company, in fact!). My answer was purely to illustrate why an open source group would likely not endeavor to create something as advanced as Type Mock simply because there's not a cost benefit ratio there for them. Most open source libraries assume a green field and that's not what Isolator is for.Research
@AndersonImes Your assumption about the "cost benefit ratio" for open source developers creating a tool like Type Mock was wrong. I can say that because I am an OSS developer who created such a tool, although for Java, not .NET. And my original motivation was simply because I wanted to write isolated unit tests for object-oriented Java code, but the existing mocking tools would not allow me to.Cromlech
A
11

TypeMock is too expensive for a hobbist like me

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

Ariannaarianne answered 9/10, 2009 at 18:1 Comment(0)
O
11

Declaimer I work at Typemock.

I'll try to answer your questions:

Is there any open source mocking framework resembling TypeMock?

The only other framework that is using the profiler API is the (commercial) JustMock.

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.

Opiate answered 11/10, 2009 at 18:59 Comment(1)
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: ayende.com/Blog/archive/2008/05/20/…Cromlech
C
5

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

Cupulate answered 7/10, 2009 at 23:15 Comment(2)
Too poor to be working on O/S as well :) (just kidding). The question is out of curiosity.Kellum
Not a great idea since now when anyone downloads your source cannot run your tests without a valid license.Glamorize
L
4

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?

Litharge answered 8/10, 2009 at 1:25 Comment(2)
Try and you'll find out - it's a not documented, very unforgiving API to work withTatro
@gkdm- have a look here- msdn.microsoft.com/en-us/magazine/cc188743.aspxXerosis
R
1

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.

Research answered 9/10, 2009 at 17:53 Comment(16)
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.Kellum
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.Research
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?Tatro
Do you think entities should have an interface (IInvoice)?Kellum
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.Research
TypeMock is useful, even if you built without testability in mind.Glum
Certainly, but if you are building for testability, the $800 - $1200 expense is harder to justify.Research
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.Cromlech
@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).Research
@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).Research
@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).Cromlech
@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.Research
@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.Research
@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.Cromlech
Lets all agree we are all wrong.Kellum
@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.Research
A
0

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).

Apperceive answered 2/12, 2009 at 7:55 Comment(1)
How do you plan on achieving this?Kellum
N
0

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.

Niemi answered 29/1, 2010 at 7:44 Comment(1)
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.Kellum
M
0

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.)

Matlock answered 13/2, 2010 at 13:9 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.