Re: [Mockobjects-java-users] Mock object tests expose class implementation details

[Steve F. <st...@m3...>]

thanks for contributing to the group.

From: "Clemmons, Scott" <sco...@fn...>
> I have similar concerns. Although I am a big proponent of mock
objects, for
> the reasons Martin suggests, I am concerned that the more mock objects
I
> create, and tests that rely on them, the more dependencies I'm
creating.
>
> In my group, I've been advocating JUnit and the use of mock objects
for
> months. In order to ease developer involvement, I've taken on the task
of
> creating unit tests for multiple subsystems. In doing so, I have found
that
> there are common internal dependencies, and therefore common mock
> possibilities.So, in short, I've begun building a mock framework, if
you
> will, around mock objects that were created by mockmaker. The test
code is
> becoming very sophisticated. But I worry that I'm creating a huge
> maintenance monster. I'm spending an inordinate amount of time
creating this
> framework, and beginning to wonder if it's worth it.

Retrofitting unit tests, whatever technique you use, is painful. In this
case, do you find that the internal dependencies in your mocks suggest
possible refactorings in your production code? Does the maintenance
problem arise because the code is not yet well factored? Sophisticated
test code is certainly a warning sign of something.

For example, it can be really tricky to set up a mock JDBC environment
if your client code goes through the whole query cycle in one go,
starting from getting a connection. On the other hand, if you have
smaller objects that wrap access to the various stages of a persistence
layer (and which can be mocked themselves), then your mock
implementation doesn't need to be so complex.

Next question, do you find that the generated mocks are OK? Would you be
better doing it by hand?

> I guess I'm asking if the investment of creating and  maintaining
large
> number of tests (and in particualr mock objects)  in order to the
protect
> the integrity of future refactoring efforts worth it?  I mean, is the
return
> value simply writing the initial tests and discovering bugs from that
> effort, and then the return diminishes rapidly afterwards?

It's your call. Do you expect never to change that code again or rely on
its side-effects? Then dump the tests ;-) It seems wasteful to go to the
trouble of understanding and implementing tests only to have to do the
same again a while later. That said, I suspect that there is room for
much better IDE support for this kind of activity (b.t.w. are you using
one of the IDE's that has help for refactoring? It does make a
difference).

Another way of looking at it is that mocks are a way of refactoring your
assertions from multiple tests into a common place.

Steve