November 6, 2009
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..
Cheers,
tfdj
Filed by The.French.DJ at 1:23 pm under Development
No Comments