CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

Be Careful Mocking Concrete or Abstract Classes

I had a question today about whether you could just mark methods as virtual on a concrete class so they could be mocked, or if you should just extract an interface and mock that.  In a statically typed language like C# the safest answer in my book is to extract an interface.  Here's a bit of a reprint from an earlier post on this subject with some additional highlighting:

I would urge a certain level of caution in mocking an abstract class or a concrete class.  For best results my advice is to only mock interfaces to avoid unwanted side effects.  It is certainly possible to mock an abstract class, doing that leads to some side effects that effectively negate all of the advantages of a mock object.  Dynamic mock object tools like NMock or Rhino Mocks can only override virtual methods.  This might not be so much a problem in other languages, but with the .Net languages all methods are non-virtual by default.  This means that some of the behavior that you were trying to remove from the test with a mock is still there.  The dynamic mock libraries work by using Reflection.Emit to create a dynamic proxy on the fly for the requested interface or abstract class.  In the case of an abstract class the dynamic mock can only intercept virtual members and even worse, the constructor function of the superclass will probably be exercised. 

http://codebetter.com/blogs/jeremy.miller/archive/2006/01/10/136407.aspx

 

 



Comments

Ayende Rahien said:

The constructor will _always_ be exercised, in both Rhino Mocks and NMock, this is enforced by the run time.
# February 20, 2006 2:23 PM

Jason Haley said:

# February 21, 2006 8:36 AM

Jeffrey Palermo said:

I would add that the only safe scenario for mocking classes are for classes that you control. In this way, you have control over constructor logic as well as what methods to mark as virtual. I've found that the need to mock a class is much less frequent than the need to mock an interface.
# February 21, 2006 2:06 PM

The Tomes Of Experience » Being driven down a path said:

Pingback from  The Tomes Of Experience    » Being driven down a path

# May 14, 2008 8:26 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#. Check out Devlicio.us!

This Blog

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

TestDriven

MVP