Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,124 | Comments: 45,475

filter by tags archive

Use the right tool for the job

time to read 2 min | 288 words

Roy is talking about certain dogmatic approaches in the ALT.Net community with regards to Type Mock. Go and read the comments, the thread is far more interesting than just the post.

Now that you have done so, let me try to explain my own thinking about this.

Type Mock has the reputation of supporting unmaintainable practices. You can argue if this reputation is accurate or not, but it is there. In fact, from Type Mock's own homepage:

Saves time by eliminating code refactoring and rewriting just to make it testable

Here is the deal, I don't think that you should eliminate code refactoring. I think that avoiding dealing with technical debt is a losing proposition in the long term.

Certainly Type Mock enables me to ignore highly coupled design and still be able to create tests for it.

Is this of value? Absolutely!

Is this desirable? I don't believe so.

Can I use Type Mock to create software with decoupled, testable design? Of course I can.

But then there is the question: what do I get from Type Mock?

Quite a lot of other goodies, actually:

  • Integration with the IDE
  • Understanding debugger func-eval (and evil feature which can cause no end of pain when doing mocking)
  • Visual Mock Tracer
  • Other things that I am not aware of because I am not a Type Mock user

The question whatever you should use it or not depends on your situation, as the author of Rhino Mocks, I don't think that I can give an unbiased opinion.


Roger Alsing

"Here is the deal, I don't think that you should eliminate code refactoring"

Incase you don't already have any tests, then you don't want to do much refactoring in fear of breaking the existing code.

So by allowing testing w/o change, you can start writing tests directly.

Those new tests will then allow you to start refactor your code w/o having to worry about breaking anything.

So this approach could allow you to get a refactored testable codebase faster than if you would have to start refactoring upfront.

Just my 2 cents..

Jeremy Gray

@Roger - the only thing you need to refactor code that doesn't have tests is some combination of the following (optimally all three, but certainly not a necessity): another pair of eyeballs, a modicum of common sense, and/or a minimum degree of caution. You certainly don't need to bring tools like TypeMock to the table to get the job done.

This may sound harsh, but here's the thing I see TypeMock used to make more than anything else: excuses. Excuses of all sorts, but primarily excuses for not making concerted efforts to improve the design (and therefore the maintainability among a million other things) of existing code.

Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 whirl wind tour: You want all the data, you can’t handle all the data - one day from now
  2. The design of RavenDB 4.0: Making Lucene reliable - about one day from now
  3. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - 3 days from now
  4. The design of RavenDB 4.0: Physically segregating collections - 4 days from now
  5. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 5 days from now

And 14 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    29 Apr 2016 - A large cluster goes into a bar and order N^2 drinks
  2. The design of RavenDB 4.0 (13):
    28 Apr 2016 - The implications of the blittable format
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats