Mock Objects

I missed Uncle Bob’s article about “Manual Mocking: Resisting the Invasion of Dots and Parentheses” and only found it through this blog post: “Think different about mock objects!”

Good stuff.

To be honest I feel like I did not keep up enough with all the Mocking and TDDing stuff in the last few years. A few days ago I started a new pet project to help me catch up a little bit. Let’s see how this turns out..

Anyway, the XPlayer blog post has some valuable (for me!) points:

One thing I learn is that mock objects are a design tool, while many people see it only as a technique for speeding up unit tests.

Because you should use mock objects as far as you can apply TDD, whereas you can design and *discover* interfaces (and roles), and assign responsibility. On the other hand, in front of a third-party library you cannot follow this process, since the code is not under your control, and you cannot modify it.

Because if you use mock objects with third-party libraries (two concrete examples taken from our recent projects: isolating our tests from the database in a Rails app, or in a java app using Hibernate ORM), you’ll write tests that *guess* the library behaviour, and your guesses may be far away from the actual behaviour.

So, I’ll repeat myself, following this “mocks as a design tool” approach, you’ll mock only types you own.

I basically quoted the whole post here.. :) Go on, read it!

I’m off to read the original Uncle Bob post now..


No comments yet. Be the first.

Leave a reply