The 5 Stages Of Mocking

When we write unit tests, we write a piece of test code to verify a piece of production code. The trouble is, production code has the nasty habit of relying on dependencies that are hard to control. Dependencies may be infrastructure dependencies like SMTP servers and databases, or may be software dependencies that are non-trivial to setup and get into the correct state for testing.

Mock objects remove these dependencies and simplify unit test code. A mock object is a stand-in replacement for a real-world domain object. For more details about mock objects, see “Mock Objects to the Rescue!”.

When I first began reading about mock objects, I did not like what I was reading. In fact, I disliked the idea so much, I entered ….

Stage 1: Denial

I found my eyes leaping over any pages containing the four letter m word. I felt confident in my gut reaction that m*ck objects were a fad –

- the same gut feeling I had when I heard of a new language by the name of C#.

As time passed, I realized the m*ck object talk was still picking up steam, and I entered ….

Stage 2: Resentment

I decided ‘object mockery’ was no longer a fad, but a placebo in source code form. Software development teams relying on mock objects would develop overconfidence in the quality of their product. These teams could watch their house of mock playing cards crumble in the cruel hands of the real world.

“Fools!”, my inner voice would yell in a Gandalf like tone. My inner voice always sounds like Gandalf or Ed Norton Jr. when I’m agitated.

As time went on, I began to write unit tests, and watch others write unit tests. Slowly … gradually … I entered ….

Stage 3: Bargaining

Some methods cry out for a unit test. Perhaps the method has logic to react to an SMTP error message, or perhaps the method has an exception handler to recuperate from a network error. These error conditions are difficult to trigger at just the right time, but I have to know exactly how the code will react. Unit tests are addictive that way. I found myself thinking about writing mock objects just to force these error conditions.

Suddenly, I was an object mocker.

The days grew long, and grey. One rainy night while sitting in my car - I hit bottom. I found myself tuning the radio to a country music station, and singing along to an old George Jones tune. I had officially entered …

Stage 4: Depression

I thought about the burden faced by the universe of software development. Any object I can think of will need to be mocked somewhere, in some program. Forget databases and mail servers. We will mock water fountains and pizza ovens. We will mock robot arms and booster engines. We will mock the stars and the sun. Yes, even the moon. The moon must be mocked.

Mock me, will you?

I’ll mock you, too….

I thought about starting a web site (Mock The World) and selling t-shirts, but I figured only lunatics and government agents would be interested and I didn’t follow through. It took some time to work out of my funk, but eventually, I reached …

Stage 5: A Wary Acceptance

I accept mock objects for what they are – a technique to simplify the creation of effective unit tests. I’m always worried, however, about assumptions. Production code contains assumptions about how other objects will behave. Mock objects have a high probability of encoding those same assumptions, and we end up testing tautologies.

 
Assert.IsTrue( mockWeather.RainTommorow || !mockWeather.RainTommorow). 

In software development, we always find a better way to build a mousetrap…

So, anyone using Mock Objects or NMock?