A while back Roy Osherove posted an offer to the altdotnet mailing list on behalf of TypeMock:
Reminder: TypeMock has offered a free Typemock Isolator ent. license for one year for anyone who has registered to the current ALT.NET site.  Also, if you're an MVP you can get the same license for free.
We do ask that once you use it, you write in your site\blog at least ONE thing that you don't like about it, or that could be better (it has to be constructive so that we can learn from it!) and hopefully things you like about it.
A fine offer, how could I possibly pass it up? Hopefully this post covers that "ONE thing".
I have looked into TypeMock before and found it to be "good" but not "good enough to make me want to switch tools". My previous comparison was fairly trivial, a comparison to Rhino which I was using, but in a problem domain that included MOSS 2007, a perfect candidate for TypeMock, as it is the pure epitome of a legacy system - yes it is possible to have a legacy system upon release.
Microsoft Makes Software That Only TypeMock Can Make Mockable!
MOSS makes life hard for developers due to a very simple, and very silly, design decision ... Microsoft like statics, they like enums, they like Internal, and they like Sealed. Far be it from me to judge their reasons behind these things, but suffice to say it makes testing a right royal pain in the posterior.
TypeMock is the only mocking framework that can help with this kind of problem, as it uses the .NET profiler to intercept the parts that other frameworks cannot reach, notably it relishes mocking things like MOSS. Unfortunately, when I was working on MOSS stuff and could have used it, there was enough resistance to testing in general, that proposing we spend a not insignificant sum on a mocking framework was tantamount to bending over and asking to be kicked very hard. I couldn't find any compelling reason why we should try to use TypeMock, over testing pretty close to the MOSS wire, but not right up to it. The solution I came up with was an abstraction of SharePoint.
No Separation of Concerns - TypeMock to the Rescue?
Now I have moved on to a new client, where my role is somewhat different. As the "Lead/Technical/Solutions/Whatever Architect" it is within my remit to recommend better ways of doing things, and in theory mocking is one of those concerns. The particular project I am overseeing is sorely lacking testing, and the concept of mocking is just not within reach.
But again I find myself with no compelling reason to recommend TypeMock, and a few reasons why not to.
Firstly, the thing it would have going for it ... the principle of Dependency Injection, or of Inversion of Control are, or at least have been, alien concepts to this code base. So a lot of code exists where in an ideal world we would be writing tests that would need to mock concreted dependencies, the "killer feature" of TypeMock.
But this needs to be weighed against some other factors.
Is Using TypeMock Helping You Pretend Your Code Doesn't Suck?
There is a lack of testing in general, and for the few tests that do exist, they are largely integration type tests, almost all actually reading and writing data into test databases. This is the mindset that the team has got themselves into - you test against a database. They therefore see little reason to test in terms of small "units" and hence do not really see why they should mock the ADO.NET components (for example) to allow them to make those same tests without a database in place - in fact they largely see the tests as being tests of the stored procedures they have written.
Then there is the concept of mocking in general. I often see this scenario, and again it is repeated, mocking is not a basic concept, before you can really get into mocking or at least can see real benefit in it, you need to have gone a long way down the unit testing road, and preferably down the test driven development road. Until you have a firm grasp on those concepts, mocking is quite a hard thing to "get" ... why would I want to mock something? Why don't I just test these 5 classes together? More experienced practitioners of TDD might give a list of reasons, but testing is an art, not a science, and until you "get" unit testing for yourself ... it just doesn't seem worth the effort.
When you do "get" unit testing, you start to think of code in a different way, you start to think of small identifiable software components that interact together, and therefore can be tested. But unless you get DI and IoC as principles, it still seems more obvious to test the 2, 3 or 4 classes that are tightly coupled as a single unit. You need to next make that step where you see that it is more beneficial to pass dependencies into classes, rather than have them contained within the class, and often you gain this insight from an inability to write good unit tests.
TypeMock To The Rescue!!!
"You know those pesky classes that you can't test because they have dependencies, well TypeMock can make those easily testable for you!"
And, indeed this is true. It can indeed save you from all those silly DI and IoC principles - why use a Strategy pattern when there will only ever be one Strategy?
Well for one thing, the tests that you found hard to write without DI/IoC were telling you something ... you had tightly coupled code, and possibly issues around the Single Responsibility Principle and Separation of Concerns.
At this point I can hear many screaming "Oh no, more damn patterns", or as a developer at a previous client said to me "I'm sick of all these acronyms".
Why The Pain You Felt Was Good Pain
The foundation of good software is understanding the basic principles that developers have come to espouse over many years, and many successful and failed projects. And your hard to test classes were flashing a big red warning light over your monitor telling you that you had some potential violations.
Now, with any pattern or principle, there are times when you can and should break it. But until you understand it to a fairly detailed degree, you are probably safer by choosing to follow it rather than ignore it out of ... well, ignorance.
Back to TypeMock saving us earlier, and allowing us to test our classes anyway ... indeed it could have done, but for a lot of developers, it would have shielded them from potentially poor code design, and just stretched their learning process out, encouraging them to write poorer quality code, as they have a tool to get around the problem they perceive (inability to test), and not realising there is a large problem lurking (their software is rigid and will be hard to extend and evolve in future)
I Don't Need No Damn IoC ... I Created This Dependency On Purpose
As mentioned above, there are times when rules are made to be broken - so I am not saying TypeMock should never be used in this scenario, but unless you know the rule you are breaking, and the reason you are breaking it, and have expressed that clearly within your code base ... just don't.
So, on this basis a mocking framework like Rhino or Moq, with their limitation on only being able to test code that is properly decoupled, would show you where your design was weak.
Experience on the Job Market
Then we have the experience factor, if I recommend a tool, I want to have some confidence that developers hired on the project will have experience with it. If someone has experience with unit testing, and with mocking, the high likelihood is that their experience is around Rhino Mocks, the least likely framework they will have used is TypeMock.
How Much???
Then there is the real deciding factor for me recommending TypeMock, cost.
Cost isn't a factor on a per developer, or per project basis, the cost of 350-450 Euros certainly isn't cheap, but on any serious software project it is a small drop in the ocean, at least with a good business and technical justification.
Cost is a major factor as the alternatives, Rhino, Moq and others, give you 95% of the functionality, can be argued to be better as they do *not* allow mocking of tightly coupled code, and more importantly are free.
On any project, when picking tools, you have to pick your fights. Do I want to expend energy getting someone to write a cheque for ReSharper for every developer, or for TypeMock? Do I want to expend energy getting agreement to use Windsor and IoC in our code base, or argue why we need to pay for TypeMock? Do I want to get agreement on NUnit over MSTest, or spend that time arguing that investment in TypeMock will pay off?
Fundamentally, a mocking framework is a very small and insignificant factor in the overall project success or failure, or even of the day to day working practices. Most other tools come as a higher priority in the decision making chain. And as such I find it hard to use (my valuable) time preparing business justifications for a tool like TypeMock, knowing full well that when asked why Rhino or Moq are not adequate for the task, that I will also be struggling for a good technical reason too.
So Where Does That Put TypeMock?
So, my conclusion is, that unless I have a legacy system to mock (put your favourite MS enterprise product in here), I would be very hard pressed to choose TypeMock as my mocking framework. Where I did have a legacy system to mock, I would be hard pressed to justify why we do not just buy a single TypeMock licence for our continuous integration server and treat tests against the legacy system as integration tests using TypeMock, and use another framework like Rhino for the tests that developers would be writing on a daily basis.
So, how can TypeMock make itself more attractive and viable? A very good, and rhetorical, question. Dropping the cost significantly may help, but presumably they have a reasonable number of customers willing to pay that price, or they wouldn't be in business, and I am thinking of a more reasonable price being in the 30-50 euro range, the level at which cost becomes insignificant as a decision point, but presumably this is just not an option. TestDriven.Net is around 130 euros, and bang-for-buck is far ahead of TypeMock in the value game.
And still ... I wouldn't want inexperienced developers wielding TypeMock at their code - I would prefer they stopped, thought and figured out why they can't write their test without it. When they figured it out, then they can ignore good principles from a position of strength.