I just tried using Test::MockObject when implementing a new feature in a program at work.
It was interesting.
Using mock objects in this case seemed like a good idea because the mocked object a) isn't fully implemented, and b) involves database access which is always nasty to get set up properly and reliably. The alternative would probably be to not do it.
The interface of Test::MockObject seems very usable, at least for my simple test.
What I thought missing was for called() (which reports whether a mocked method was called) to report the number of invocations, so now I call clear() a lot all over the place. Maybe I don't understand the next_call() method, and that's what I should be using instead. But really what I'd like to know is just how many times a method was called since last time, so that seems... not simple enough :)
One thing that I used was to redefine a mocked method over time so that it would either die or not depending on the state of the object was supposed to have. An example of this could possibly be added to the synopsis (I had to go look at the code to get to know that it worked).
An effect of using a mock object was that I could focus on the class at hand 100% which provided a very peaceful and focused development process. The mocked methods don't exist yet in the mocked class, and now I didn't have to jump here and there to implement missing pieces. So this also provided me with an interface for what's missing in that class. Nice!
A downside with using a mock object is that I now have a stronger coupling between the tests of class A and the implementation of class B. I'm not sure I'm entirely happy with that. I can imagine that some classes gets mocked in a _lot_ of other classes' tests, and that this may possibly hinder refactoring of the mocked class.
This would be true especially in the case of a system with lots of hard-to-test legacy code, which both needs lots of tests (probably with mock objects just to make it work with all the depencies that are bound to be there) and needs a lot of refactoring.
Another effect is that the tests themselves are more complex than normal, so there's a higher risk of messing things up. I have to get both my implementation right, _and_ the fake logic it works with.
Now I'll go ahead and implement the mocked methods in the second class. We'll see if they are the right ones :)
