So Over Mocking Frameworks

In which our hero peddles more of the stuff that wasn’t good enough to make it into his TDD Session, and passes it off as an interesting blog post. Welcome to the blog equivalent of the “extras” section of a DVD.

During the course of preparing and presenting my session on Test Driven Development, I had quite a few interesting conversations with quite a few interesting people. Some were the face to face kind of chats that you inevitably have after presenting a session, some were via email.

One theme that popped up more than once was the notion of being “over” mocking frameworks. And when I say “over” I mean it in the “girlfriend from college that you’d rather not see any more” sense of the word.

It appears that when it comes to mocking, TDD practitioners go through a number of phases.

• Ignorance – How to I test this object, it has all these dependencies?
• Interest – Hmmm I can create classes that implement the same interface as a dependency.
• Excitement – Holy crap, mocking frameworks are da shizzle, I want to use them everywhere.
• Hmmm – Why is it complicated to do this with a mocking framework. A hand coded class would be so much simpler.
• Disillusionment – Holy crap, mocking frameworks are a pain, I don’t want to use them anywhere.
• Righteous Indignation – Dude! You’re using Mocking Frameworks? that’s like so 2009.
• Perspective – Mocking frameworks, handrolled? Meh! Both have their place

As with virtually everything else in life, extreme views for or against Mocking frameworks are unlikely to be helpful to anyone. They’re a tool. Ignoring them completely (or consciously not using them) is no more helpful than surrendering to them and using them blindly.

In a future post I’ll look at how to mitigate some of the issues that cause people to “get over” Mocking Frameworks. I’ll also look at some of the issues that need to be addressed when using hand rolled mocks and stubs.