Two Guys Arguing

Mocking frameworks are like cologne

Posted in software testing by benjaminplee on 11.20.10

Mocking frameworks are like cologne …

they help make your tests smell better, but they can cover up some really stinky code.

I was working my way through some old bookmarked blog posts when I ran across Decoupling tests with .NET 4 by Mr. Berridge and it reminded of a discussion I had a few weeks back while teaching a refactoring workshop.  The discussion centered around the question: When should I use a mocking framework and when should I use real objects or hand-coded stubs?

*** I will leave the questions of the differences between stubs & mocks and the merits of testing in true isolations versus using real objects for another day ***

Lego FriendMocking frameworks like Mockito or Moq are great tools, but lately I have been finding myself using them less and less.  I have found that the more I use mocking frameworks the more easily I break the Single Responsibility Principle. Now, this obviously isn’t the fault of the tool.  It is my fault.  And my pair’s.  The real problem is that we grew accustomed to using the tool and began to lean on it as a crutch.  As we added more features our code took on more and more responsibilities; but we didn’t feel the pain directly because Mockito was doing more and more of the heavy lifting.

In Kevin’s post, he specifically talks about TDDing an object with many dependencies and the pain of updating each test as new dependencies were added.  Now, I have a ton of respect for Kevin and his code … but I wonder if the another solution to his problem would be to re-examine why the object needed so many dependencies.  Is it doing too much?  Could these dependencies be re-described and possibly combined into the overall roles they fulfill?

Kevin’s solution was clever and a nice tip to keep in my pocket.  The devil is in the details.  As I try to “follow the pain” I am trying to write more hand-coded stubs and evaluate any time I find myself relying on side-effects to verify how my code works.  Wish me luck.

3 Responses

Subscribe to comments with RSS.

  1. Kevin Berridge said, on 11.21.10 at 9:24 am

    Good call Ben! From an “object role stereotype” ( perspective, the object I was testing might be classified as a coordinator. Thus all the dependencies. But your suggestion of combining some of the dependencies into a single umbrella class is interesting. I may be missing a domain concept that could help combine and abstract some of the logic…

    In fact, I’m pretty sure I wouldn’t use that technique exactly as described today. It was later pointed out to me that the use of the default mock w/ no behavior specified was a smell of it’s own. This probably deserves a follow-up post on my part… But in short, while the given test may not care to verify anything on one of it’s dependencies, it was very naive of me to assume it was OK to not even describe the mock’s behavior. Now-a-days I create a repository of “working” default mocks (which could be mocks or stubs) and would use one of those instead of an empty default.

  2. Zac Duncan said, on 11.21.10 at 2:34 pm

    I don’t think it’s quite like that.

    There’s a fairly old codebase at our work that was written from a strongly anti-mocking framework POV. The result is god classes, insanely deep levels of coupling and massive, hand-written mocks that are so complicated that they themselves have to be unit tested.

    There’s another side of that codebase that’s been written with a heavy, strict mockist POV. The result was an anemic, somewhat overly complicated design and brittle tests that don’t support refactoring.

    Here’s the thing, if you don’t pay attention to simplicity and cleanlines then any testing approach that will wind up hiding or encouraging poor design.

  3. Eric Neunaber said, on 11.28.10 at 7:46 pm

    I felt that one of the “signs” that our mocked class was doing too much was in how hard it became to setup the object for test. If my test setup became longer than three to five lines, I have to wonder if it’s doing too much.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s