In the last post I introduced mock objects and talked about some of the various flavors of fake objects.  In this post I want to talk about when and why you would use a mock object.  The main benefit of using mock objects is increased testability throughout a system.  A secondary benefit of mock objects is an improved ability to do continuous design within your code.

Improved Unit Testing

Let’s look at the usage of mock objects applied to the desired qualities of a good unit test.

• Unit tests should be atomic.  TDD style unit tests should be small tests that cover a specific, granular area of the code.  The code under test might interact with other classes or external systems, but at the moment you only want to worry about the proper functioning of the class under test.  You can preserve the atomicity of the unit test by replacing the external resources and coding dependencies by using a mock object to establish an expected behavior.  You specify exactly how the mock object is going to behave, so any unit test failures are now traced to the class under test.  When I was an engineer one of the hardest tasks in any engineering calculation was modeling boundary conditions.  A boundary condition is a point in the system with known behavior.  Inside your calculation you could ignore anything outside the boundary conditions.  The way to make your life easier was to establish boundary conditions so as to minimize the number of variables within any engineering calculation.  Mock objects are conceptually the same thing as boundary conditions.  One of the primary claims for the efficiency of TDD is the radically reduced time spent debugging code.  My experience that claim is true, but only when you write fine-grained tests.  My ratio of debugging time to coding time dropped precipitously when I started to become proficient with mock objects.  Please be aware that excessive mocking calls in a unit test can lead to unit tests that are too tightly coupled to the internal implementation of the very dependency you’re trying to mock.  This can make your code very difficult to refactor because the unit tests are brittle.
• Order Independent and Isolated.  You should never assume that the tests are run in any certain order.  Each test should start from a completely known state and clean up after itself if necessary.  One of the biggest mistakes in writing unit tests is allowing state or the results of one unit test effect a different unit test.  It’s hard enough to troubleshoot testing failures.  Having to look through other unit tests to find the problem is time intensive and counterintuitive.  Static properties, singletons, and repositories are a common culprit, but the worst culprit might be testing against the database.  The entire purpose of a database is to maintain state, and that’s not a particularly good trait inside a unit test.  Using a mock object in place of any kind of stateful dependency will isolate your unit test from external state and make your unit tests order independent and isolated.
• Intention Revealing.  This quality goes back to interaction based testing.  If the responsibility of the class being tested is to direct or coordinate other classes, then using a mock object inside the test may make the test easier to understand.  On the other hand, excessive mock object setup may make the unit test a lot more difficult to understand.  My advice is to simply pay attention to what you’re coding.  If it feels like using a mock object is making the test harder, back up and find a different way to write the test or change the class structure.    I’m going to come back to this topic quite a bit more in a later post.  I got pretty irritated at a junior/junior pair last year when I found out they had spent the better part of a day trying to write a unit test by mocking ADO.Net with no real success.  When I saw what they were doing I convinced them to change direction and create a new coarse-grained interface that would encapsulate the ADO.Net calls and would be easy to mock.
• Easy to Setup.  This quality might be a bit in the eye of the beholder.  I’ll talk about this in much more detail in the next post or two, but a lot of mock scaffolding in a unit test is a code smell.  One very significant reason to use mock objects is to avoid the need to setup external resources into a known state for each test.  Think of a database.  You might only need a particular row in the database for the test, but due to the (necessary) evil of referential integrity that one row might require a whole bunch of other data first.  Even worse is something like a web service, a messaging queue, or the all time worst IMO – Active Directory.  More specifically, here’s a list of reasons to forgo trying to setup an external resource to behave in an expected way:
  • It’s often more work to write the SQL scripts than it is to setup the mock expectations or stub returns.  Less work is always good
  • Setting up the external state often obfuscates the test and can make the test harder to understand
  • Having external resource setup inside an automated test often tightly couples that test to the inner workings of the external dependency.  Loose coupling in automated tests is every bit as important for success as loosely coupled code.
• Runs Fast.  Making your automated tests run quickly isn’t a luxury, it’s a necessity.  Except for the very beginning of a project you should expect automated testing to be the performance bottleneck in your automated build process.  It’s not a good thing when you start frequently hearing the phrase “we’re in CC.Net time.”   I had a post on this a while back here.

Designing for and with Mock Objects

I love the “mock as spy” analogy, but here’s an additional way to think about the role of a mock object.  In the movie and TV industries child actors are expressly limited in the number of hours they’re allowed to work in a day or week.  The director will use adults of roughly the same size to be “stand-ins” for the child actors so they can accurately storyboard the scene with the set, the lights, and the camera angles (I know all about this because of a classic Seinfeld episode years ago).  The director and the camera crew can get the scene completely setup without cutting into the child actors’ limited quota of hours.  Mock objects can be used in much the same way.  It’s what I like to think of as “Client First Development.”  Falling back on the Model View Presenter pattern as an example yet one more time, you might build a screen in a couple pieces:

1. Presenter – handles the user information flow logic and intermediates communication between the actual screen and the backend services
2. IService/Service – the gateway to the backend business or service layer
3. IView/View – The actual screen

In this case I would define Presenter as the client of the services provided by the IService and IView interfaces.  I’ve consistently found it to be more efficient to make the development of the Presenter (the client) drive the signature of the IService and IView interfaces.  The Presenter is largely coded first with the dependencies mocked.  I’ve found this approach to be consistently more efficient than trying to drive the development from backend to front.  The requirements of “service provider” classes or modules are completely determined by the needs of their clients.  Building a service provider before the client will very frequently result in rework to the service provider when you discover that the client has different needs than you previously expected.  By using mocks or stubs I can narrowly focus on the design of the client and then turn and implement the resulting interfaces for the service provider.  Yeah you can give me the tired old line of “if you just did more research upfront…” but no design can ever accurately said to be “done” until it’s fully implemented and tested.

Another way to think about mock objects is that they’re like doing a UML sequence diagram, but in code. 

I’ve sarcastically described TDD in the past as Mock-Driven Design, but it does work.  You need to very consciously consider testability in almost every design decision.  Very purposely consider how to spread responsibilities between classes to maximize testability.  I am very much cognizant of utilizing mock objects when I do class and namespace level design.

Here’s a quote from Jeffrey Palermo this very afternoon – “do you know how nice it is to get a piece of code into NUnit or the debugger without having to install every single other service?”  Yes Jeffrey, I know exactly how you feel.

What to Mock?

So we come to the question of what to mock?  My rule of thumb is to mock anything that is involves any kind of call or access to things outside of the AppDomain.  Mocking the data access layer when you’re testing business or service layer logic is an obvious example.  Here are some other examples that I can remember using:

• WinForms code
• ASP.Net objects – user controls, HttpContext objects (but I’d advise against doing this directly)
• Web service proxy classes.  Absolute no-brainer. 
• Database access code, persistence
• Active Directory access
• Gateways to weird legacy code or systems – and almost all legacy code IS weird
• Facades to other subsystems
• Remoted classes

Next up is a discussion on the best practices for mock objects, including a section on when NOT to use mock objects.