It is a good thing, but can be frustrating as we all like shortcuts.
The cost is when you have a hug suite of unit tests (good thing!) but they are on moderately coupled code (eh thing), and you want to refactor some smelly thing (good thing!).
You do, you *know* it behaves the same way.
50% of unit tests now fail with a message like:
"unexpected call 'getFoo()' on 'foo'"
And you rollback your change because fixing the tests is a bigger task than you are willing to stomach for the small improvement.
The problem here was that it is easy to make unit tests very fragile when working with even moderately coupled code -- and doing whitebox testing. If you are passing a mock into a class in constructor, and you know what the calls against it will be, you tend to mock.expectAndReturn(..) on them.
This is fine, and is correct.
When you put a mock in an object, which is used by what you are testing (easy to do) in order to make behavior correctly you get non-obvious dependencies for internal changes. Really the rule should be "ruthlessly obey the Law of Demeter."
Does this make any sense?
-Brian
On Jul 24, 2004, at 3:48 PM, Ugo Cei wrote:
Il giorno 24/lug/04, alle 21:00, Brian McCallister ha scritto:
I love mocks, but they do force you to decouple.
Isn't this supposed to be a good thing, or there are hidden costs?
-- Ugo Cei - http://beblogging.com/
