The Case For Typemock
I just wrote an email to someone regarding Typemock. We were discussing why they don't think Typemock holds the values that other mocking frameworks hold when I suddenly realized what I've been wanting to say all along about Typemock, and why it's a viable option for organizations (disclosure - I recently started working at Typemock)
Before you read what I wrote, you can read posts that say "don't use Typemock" here, here,here and there are others. Most fear that Typemock will make it easy for you to write non testable code, or that your design will suffer for it. You can read my thoughts on this here and here.
The following is in argument of people saying that Typemock contradicts the agile values of TDD and unit testing by supplying workarounds for common testability problems.
The trick is to look at the bigger picture. sometimes you are looking at details so up close that you lose site of the whole idea behind mocking frameworks to begin with. Making the team more agile.
Easier to digest
Typemock is to Rhino.Mocks as Scrum is to eXtreme Programming- one is much easier(less scary) to swallow to the uninitiated than the other, but they eventually lead to the same overall result - a team that can do a better job with better feedback.
It is a business oriented mocking framework. It speaks in a language that managers who don't feel "agile" can understand. It will help them write tests for existing code, it will help them write tests more easily on new code as well. It will be a bigger ROI than the other frameworks because of these benefits.
That, in turn, means that Typemock is easier to adopt in non agile\unit testing organizations, but it still plants that agile seed in there. The developer that today uses it to write tests against their legacy code, will write unit tests with it tomorrow on greenfield code. it is their choice when to use it, but at least now they have a tool that was "insertable" into the organization which can now be used for more and more agility in the dev team.
A bridge between Agile and Non Agile
Typemock is a "bridge" between the pure, extreme, agile world and the business oriented, manager facing, legacy ridden, agile fearing world that we all love to whine about so much. Because it tries to speak to that world, and to those managers who don't want to give up their existing OO beliefs (designing for testability?), it also feels controversial to the pure agile world.
it is neither here nor there. not pure Agile\Testability but also allows agility through unit testing if you use it right. That means it's also in both worlds - it connects the business and agile world by making writing tests simpler, and the trouble of learning the techniques is easier to explain.
Typemock can help drive change where others can't
Typemock can drive change in non agile organizations sometimes more than other frameworks such as RhinoMocks or NMock, simply because it will cater to needs (such as legacy code, non testable code) that the other frameworks do not make possible. That is what makes it unique, and what makes it so different that the agile world doesn't quite know how to swallow it.
Don't be dogmatic
And if you really feel that you wouldn't recommend Typemock because it doesn't subscribe to the way you think things should be done, aren't you being a little dogmatic? agile is about embracing what works for a particular team and Typemock certainly does solve lots of problems for real teams. Just because they don't use concepts we're used to as often, doesn't mean they aren't becoming more and more agile every day.
Update: I posted a 10 minute intro video to Typemock here.