cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: Mock objects
Date Sat, 24 Jul 2004 20:21:01 GMT
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?


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 -

View raw message