Menu
I hope this question is not 'controversial' - I'm just basically asking - has anyone here purchased TypeMock and been happy (or unhappy) with the results?
We are a small dev shop of only 12 developers including the 2 dev managers. We've been using NMock so far but there are limitations. I have done research and started playing with TypeMock and I love it. It's super clean syntax and lets you basically mock everything, which is great for legacy code.
The problem is - how do I justify to my boss spending 800-1200$ per license for an API which has 4-5 competitors that are completly free? 800-1200$ is how much Infragistrics or Telerik cost per license - and there sure as hell isn't 4-5 open source comparable UI frameworks... Which is why I find it a bit overpriced, albeit an awesome library...
Any opinions / experiences are greatly appreciated.
EDIT: after finding MOQ I thought I fell in love - until I found out that it's not fully supported in VB.NET because VB lacks lambda sub routines =(. Is anyone using MOQ for VB.NET? The problem is we are a mixed shop - we use C# for our CRM development and VB for everything else. Any guidence is greatly appreciated again
Edit: hmm.. I can't find Isolate.WhenCalled() equivalen in Moq... Any help here? I want to stub/mock out a ReadOnly property of a CONCRETE object (not of a mocked object)... I could easily do this with Isolate.WhenCalled with TM. How with Moq???
803
Yes, when you download Isolator++ Professional you can use that version free for life.
Stub - an object that provides predefined answers to method calls. Mock - an object on which you set expectations. Fake - an object with limited capabilities (for the purposes of testing), e.g. a fake web service. Test Double is the general term for stubs, mocks and fakes.
The purpose of mocking is to isolate and focus on the code being tested and not on the behavior or state of external dependencies. In mocking, the dependencies are replaced by closely controlled replacements objects that simulate the behavior of the real ones.
Mocking is a way to replace a dependency in a unit under test with a stand-in for that dependency. The stand-in allows the unit under test to be tested without invoking the real dependency.
The project I'm on used TypeMock for many months. We actually just finished completely phasing it out in favor of Moq (completely free Apache 2.0 licensed mocking framework). You should definitely check out Moq if you haven't seen it. In addition to having the most intuitive syntax of any mocking tool I've seen, you get the benefits of compile time type checking. Very nice.
TypeMock has one significant benefit over Moq as I see it. Namely, it can mock anything. This includes sealed classes, non virtual methods, concrete types and pretty much anything else you can throw at it. If you're doing ASP.Net, and depending on how your code is structured, it can actually make mocking ASP.Net code behind classes a possibility. Quite neat.
However - We found that if you structure your code well, the benefits of TypeMock do not outweigh the price. Further, if you can't mock something with Moq, it probably means there's a smell there. TypeMock lets you be lazy, and I think that the code can suffer as a consequence. Moq and other mocking frameworks like it (RhinoMocks comes to mind) do make you think about your code as you're writing it, especially in terms of testability, but I would argue that's a good thing :) Further, our team ran in to several headaches trying to deploy TypeMock to our continuous integration server.
Long story short, TypeMock is a very powerful tool. As you mention, for unit testing old legacy code there aren't many better products. However, 1000 bucks gets you one TypeMock license, OR, a couple of resharper licenses, almost ten TD.Net licenses, a new continuous integration server or many other things. My own experience suggests that it's not worth it, but your mileage may vary!
71
+1 Eric's answer - completely agree.
It's similar to MSTest's private accessors mechanism - there's a very strong chance you're looking at the problem wrong. If you end up having to use some technical McGyvery to test something, somebody is Doing Something Wrong.
Of course, the next thing that gets trotted out as a counterpoint is that there are cases where someone has already Done Something Wrong (Yes, I'm looking at you, SharePoint, WebForms and friends) and you really do need to do some complex in order to deal with the situation as it is right now.
Fighting battles like this can often be a huge timesink which in retrospect rarely makes you feel good. It's similar to saying "Oooh, I definitely need to get some form of testing on this, and the only thing that's going to work is UI automation because of where we are". Going down that road:
pulls energy away from a the real solution to the real problem - getting proper testing all the way down of different forms and granularity over time and facing the fact that there's lots of wrok to do and techniques to learn on the road to having a system you can feel comfortable about given the Legacy starting point that 97.92% of projects start from or tend towards at various stages
leaves you with a set of 'Coded UI tests' that you won't be happy with
One more thing - MSR has a Moles project they've been pimping lately which does the same sort of thing as TM, i.e., runtime rewriting via profiler hooks. Might be useful to people that feel they want/need to have something in their arsenal as backup if you ever do really run out of road with Moq in a real world scenario that you cant refactor your way out of and end up in a better place.
29
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
