Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
TypeMock - Powerful, but Needed?

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.

Posted 05-01-2008 3:33 PM by Jak Charlton



Kyle Baley wrote re: TypeMock - Powerful, but Needed?
on 05-01-2008 2:34 PM

I have it on my review list too but the niche I'm picturing for it is in brownfield applications that are nigh untestable. Yes, you should make it more "testable" but if you are dropped into a large codebase, that may be more utopian than the budget allows. Ideally, when fixing a bug, we'd want developers to write a failing test to expose it. But in many brownfield apps, fixing seemingly benign bugs may involve "a slight re-architecting" of the app to make it testable in the traditional sense. In the right hands, I would consider using TypeMock to write the failing test at least as a stopgap measure.

Hadi Hariri wrote re: TypeMock - Powerful, but Needed?
on 05-01-2008 6:25 PM

Basically what you're saying is that you want the testing framework to enforce good design and at the same time you're concluding that those that use TypeMock don't know/need/use DI or design loosely coupled systems. In both cases I disagree with you, as I have on the list and as I summed up in my recent blog post.

Developers need to learn the previous concepts, not be forced into it by a testing framework. They need to decide when it's appropriate, when it's not, and not blindly do something just because it needs to be tested. Which brings me to the question that was left unanswered numerous times. Why do you abstract everything?

Jak Charlton wrote re: TypeMock - Powerful, but Needed?
on 05-02-2008 2:15 AM


I think if you read up a bit you will find I covered that quite well with:

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

If you understand why you are creating tightly coupled code, and have expressed that well within your code, then you don't need loose coupling, IoC, DI or any other fancy buzzword. In that case TypeMock may help - but why do you need to test that tightly coupled code in isolation if it is tightly coupled?

Insane World - Casey Charlton wrote Castle Windsor - One Small Step Towards Better Software
on 05-02-2008 2:21 AM

We currently develop software in a fairly piecemeal and disjointed fashion. The software we develop could also be fairly accurately described as monolithic. There are many problems that come with monolithic code, it becomes hard to maintain, hard to evolve

Hadi Hariri wrote re: TypeMock - Powerful, but Needed?
on 05-02-2008 7:45 AM


As I mentioned on the mailing list, there are times when circumstances don't allow you to test certain pieces of code in isolation and yet it is justified to be tightly coupled, i.e. no dependency is injected.

Again, with the statements you quote I really think that you're putting the responsibility of good practices on the testing framework and not on the developer. It's easy to implement loose coupling when the testing framework requires it for testing. When you come to test something that's not loosely coupled you'll see the pain. However, I think that doesn't justify that you need to have no dependency in your code. And I think if you understand the concepts, TypeMock allows you to still maintain good design but doesn't enforce design for testability.

Weekly Links 2 « Davy Brion’s Blog wrote Weekly Links 2 « Davy Brion’s Blog
on 05-03-2008 7:17 AM

Pingback from  Weekly Links 2 « Davy Brion’s Blog

Casey Charlton - Insane World wrote Is Duplicitous?
on 05-21-2008 6:29 AM

Roy makes a number of accusations about the community, particularly centred around their espoused

The Inquisitive Coder » Blog Archive » Weekly Links 2 wrote The Inquisitive Coder » Blog Archive » Weekly Links 2
on 05-24-2008 10:14 AM

Pingback from  The Inquisitive Coder  » Blog Archive   » Weekly Links 2

Mark wrote re: TypeMock - Powerful, but Needed?
on 06-25-2009 7:31 PM

TypeMock does not force developing for testability.  Rhino, Moq etc. force a particular development style, which is not really appropriate in all cases.  As much as I would like to have a free mocking framework, they are all pretty much unusable unless you are willing to capitulate to their demands.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)