The analysts and pundits have declared agile and unit testing mainstream.  That’s great news if you’re in the mainstream.  But what if your company was caught in an eddy?  Now you are trying to bring your company up to speed and add unit tests to your code base, but where do you start?

I’ve been unit testing my .NET software ever since NUnit was first released, and practicing Test Driven and Behavior Driven development for at least six years.  As I’m sure you can tell from my blog posts and the talks that I give, I’m a big fan.  But getting started can be hard.  It takes time, although it’s definitely time well spent.  The rewards are huge and very well proven.

Writing that first test, transitioning from zero tests to one test, is usually the hardest thing to do. Where do you start?  The first thing you need to do is get a grip on mocking.  And I don’t mean making fun of other developers.  Why should you use a mocking framework?  You can’t effectively isolate your unit tests without a mocking framework.  You can read my blog post on Why Mocking Matters and how I Got Started Mocking.  

I’m proud of those posts, but let’s talk about some reasons that maybe hit closer to home.  With that, let me introduce to you my top 5 reasons to use a mocking framework.

5. The 80’s called – they want their code back

SOLID isn’t just a term the hipsters used back in the day.  It’s the gold standard for developing software.  But you’ve just inherited software that looks like it was written when floppy disks were still floppy.  And you could use a whole punch to make them double sided!

You want to refactor your code to make it more SOLID. Or at least a lot less squishy. One thing that we’ve learned in the modern age of software development is that you shouldn’t change any code unless you can verify the effect of those changes with tests.  But most legacy code needs to be changed before it can be tested.  Chicken, meet egg.

The solution this of course is a profiled mocking framework.  With the ability for future mock, mock static/private/sealed objects, and mock by example, plus many more features, you can create artificial seams in your application to get those tests in place and ensure that the refactoring that you do doesn’t produce any undesired side effects.

Spray of Light

Spray of Light/ Fernando de Sousa/ CC BY

4. The Application is the Unit of Work

Dependency injection is to prevent getting the flu, right? Seriously, dependency injection (DI) is arguably one of the most important components of SOLID. You look at the code base, and there aren’t instances of dependency injection or any seams in the application, and each code behind file has 5,000 lines of code.  A unit of work (in relation to unit testing) is the smallest isolatable section of code.  In a perfect world, .NET this is a method.  The smallest isolatable unit of work in this case is, well, the entire application! 

This is where a profiled mocking framework comes in with that ability to future mock an object. Future mocking allows you to create a mock of a concrete object in your unit tests that gets invoked in the system under test, even though the system under test explicitly instantiates the object.

Daily injection/ Sarah G/ CC BY

3. Where clauses?  We don’t need no stinkin’ where clauses!

You’ve spent a lot of time getting the data in your test database just right. You can effectively test your software and get predictable results.  Granted, it’s not really unit testing since the application is the unit of work (see reason #5 above).  But you are making progress!

All of a sudden, all of your tests are failing. You spend the better part of a day trying to figure out what the heck happened.  Finally, you discover (usually by accident) that someone executed “delete from customer” and wiped out all of your data.  Hopefully you made a backup!

By abstracting dependencies and replacing the calls to the data access layer with mocks, you can prevent this problem.  Each mock is arranged to provide the data needed for the test, and never actually touches the database.  This eliminates the noise of outside system failures or changes that can make unit tests fail.

imageIpswich, Waterfront, Ipswich Campus, The Big Question Mark Sculpture/ Martin Pettitt /CC BY

2. [Ignore] is the most popular attribute in the code base

Someone before you made the valiant attempt to add unit tests, and configured the build server to run those unit tests, and fail the build if any of the tests fail.  Bravo!  However, that developer has either left the project or has been beaten into submission by the legacy codebase, and has given up.  Now, instead of maintaining the unit tests, every just marks the failing tests with the Ignore attribute so they don’t run, thereby not breaking the build.

Tests that have too many concrete dependencies are inherently brittle.  All that should be executed from the system under test is the unit of work.  All other dependencies should be replaced with fakes or mocks.   Fakes take a brutal toll on developers since they are maintenance heavy.  Mocking out all of a system under test’s dependencies isolates the tests from changes outside the scope of what the test is trying to accomplish, making it less fragile, and more likely to be maintained.  When a failing test is the exception instead of the rule, it tends to get fixed instead of ignored.

imageIgnore/ Frank Hebbert /CC BY

And the number one reason to use a mocking framework…

1. Your coworker can’t code his way out of a paper bag

You keep getting bugs assigned to you, and every single time, it turns out that the bug is actually in an object that your work depends on.  And every single time you have to fix it.  The bug counts are mounting, and you find yourself buying the weekly donuts, even though it’s not the code that you developed that is causing the problem!

The solution?  Don’t depend on his code.  Write unit tests that exercise the code that you develop, and isolate all dependencies with a mocking framework.  That way, when the bugs come in, you can verify that the software you developed is behaving as expected, and the problems are downstream.

imageNoah with his new paper bag hat/ ella /CC BY


Obviously, this post was written a bit tongue in cheek.  Unfortunately, I’ve encountered every single one of these situations in my software development career.  To find out more how JustMock can help you with this and any of your other software nightmares, download a free trial and try it today!

What are your reasons for using a mocking framework?  Post them here in the comments.  I’ll write a follow up of the top 5 reason from the comments, and if you are the first to suggest one of the selected suggestions for the follow up post will get a free license to JustMock!

JustMock banner

About the Author

Phil Japikse

is an international speaker, a Microsoft MVP, ASPInsider, INETA Community Champion, MCSD, CSM/ CSP, and a passionate member of the developer community. Phil has been working with .Net since the first betas, developing software for over 20 years, and heavily involved in the agile community since 2005. Phil also hosts the Hallway Conversations podcast ( and serves as the Lead Director for the Cincinnati .Net User’s Group ( You can follow Phil on twitter via, or read his personal blog at


Related Posts


Comments are disabled in preview mode.