Derik Whittaker



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
Options Wanted: How do I handle my Mocks

I am looking for feedback from the group.  I am pretty new to using mocks for my unit tests and I am not sure what the standard approach in the community for usage of mocks in regards to how/where they are stored in your test application.

After refactoring some of my tests to use mocks I quickly noticed that I was littering the same mock creation code in many of the unit tests.  So, the first thing I did was create a local helper method inside my test. However, as I continued my refactoring I was started to create the same helper method in many classes.  After noticing what I was doing, I knew there had to be a better way to do this.

What I am thinking of doing is creating a ‘Mocks project’ that will only contain static methods that can be called (with and without construction params) to build and return a mock for a given interface.  The reason I want separate class for this is because 2 different projects use the same backend, but each have their own test suite.

Does this sound absurd? 

Thanks for any insight.

Posted 04-17-2007 7:35 AM by Derik Whittaker



Jeremy Miller wrote re: Options Wanted: How do I handle my Mocks
on 04-17-2007 9:07 AM


Testing is one of the few places where I'd rather just duplicate the mock object expectations to make each test easier to understand.  I will occasionally use helper methods inside unit test fixture classes for repeated mock object setup.

Now though, here's another case.  Say you have 5 or more unit tests that all start with the same 3-4 mock expectations and varies from there.  What that tells me is that I might want to refactor the code to isolate the variable part of the code away from the part that behaves the same way to eliminate the repetetive mocking.

Dave wrote re: Options Wanted: How do I handle my Mocks
on 04-17-2007 9:54 AM

I also tend to do a lot of duplication with my tests. In the cases where I am expecting a collection to be returned I will have a factory method to return that collection but that is usually about it.

One thing I do is have two test assemblies. One only contains mocks and tests the interaction between objects. The other test assembly are functional tests that actually will hit the database / other expensive resource. This separation allows you to quickly test your application and separately test slow/expensive items.

Jeremy wrote re: Options Wanted: How do I handle my Mocks
on 04-17-2007 11:34 AM

Hi Derik,

I second both of those comments.  I view the unit tests as the best form of API documentation available so new people on the project can easily learn how to interact with your classes.  With that in mind, I'm generally much more lenient in regards to code duplication and such since readability of the code is paramount.  That said, I normally do move the creation of the mock factory (in Rhino.Mocks this is the MockRepository object) to the SetUp simply to prevent reinitializing it in every test.

I also agree with the 'two test suite' concept that Dave mentions.  In my company we refer to these as Connected versus Disconnected tests.  The Disconnected tests contain the mocks and usually don't talk to anything outside of the target assembly.  The Connected tests actually talk to live web services, databases, or anything else that would typically be mocked.  There are usually similar tests in each although this does not necessarily have to be the case.

The entire idea is that we run our Disconnected tests on our local machine as part of our development process since they run quickly and efficiently.  Since our Connected tests take a bit longer to run we typically only run them on our build machine as part of our continuous integration process.

Hope this helps,


Billy McCafferty wrote re: Options Wanted: How do I handle my Mocks
on 04-17-2007 12:38 PM

Recently, I've been maintaining mock factories which helps centralize mock creation and the business objects they (may) return.  But I'm starting to see that the redirection that the factories add makes the unit tests a bit harder to understand.  Like Jeremy suggested, Gerard Meszaros, in his upcoming xUnit Patterns, also suggests moving mock creation to the setup method: .  I think the added clarity would be worth the possible duplication of code.

As for keeping tests in one assembly or two, I've always liked having them in one but to categorize service-tests (DB, "real" membership provider, web smoke tests), accordingly.  In this way, it's easy for me to open NUnit, select the category I want to run, such as "DB Tests" and run them without having to open different projects.  The only downside that I've encountered is that TestDriven.NET doesn't pay attention to categories.

Raymond Lewallen wrote re: Options Wanted: How do I handle my Mocks
on 04-17-2007 3:58 PM

I have duplicate code when mocking.  Jeremy is right in that you should definitely look at those tests that are testing the same expectations over and over, but there are certainly circumstances where the duplication would be necessary.  One of the advantages of unit tests in general is their clarity and singularity of purpose, so don't do too much to lose that.  I might have 2 tests that are both expecting the same things to happen, but under a different set of circumstances, such as the first test fires a Load event and then a Save event.  The 2nd test wants to test that the same expectations are met but only if the Save event is fired and the Load event is skipped.  To me, code duplication in tests helps keep each test as clear as possible and lets it stand on its own just that much better.

Eber Irigoyen wrote re: Options Wanted: How do I handle my Mocks
on 04-17-2007 10:37 PM

I agree that with unit tests there's some duplication, but you have to draw a line somewhere, extremes are not good either

I do agree with Jeremy that you might have a different issue

Corey Grusden wrote re: Options Wanted: How do I handle my Mocks
on 04-24-2007 11:05 PM

Refactoring your test code is great and it helps clean up tests, but it's a case-by-case basis on how much they need to be refactored as far as dynamic mocks go in my opinion.

I create helper functions for certain setup code too, but when it comes to dynamic mocks I usually try to leave as much as possible in the test-method itself.   By leaving that setup code in the test it doesn't add an extra step for the testing novices that come behind me that look at the code and have to look at another class.  Slight redundancy over 3-4 tests that are doing the same thing is OK.  The size of each of the test should have a small footprint anyway.

As for the the Two-Assemblies , one for connected and one for disconnected tests. I'm down with that concept.  If you don't want to keep up with two assemblies, you could put your tests into NUnit-TestCategories of "Connected" or "Disconnected" and just run tests on certain categories.

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)