mockobjects-java-users

RE: [Mockobjects-java-users] Mock object tests expose class imple mentation details

[Clemmons, S. <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.  
 
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? 
 
What is your experience with large projects and the utilization of mock
objects with them?
 
Thanks,
 
Scott
 

-----Original Message-----
From: Martin Bayly [mailto:mar...@ho...]
Sent: Monday, February 25, 2002 2:10 AM
To: moc...@li...
Subject: [Mockobjects-java-users] Mock object tests expose class
implementation details


I've been using mock objects on a new project for the last few weeks and I
really like the level of isolation I can achieve between the class being
tested and other domain code on which the class depends.  They make tests
simpler to setup and easier/faster to run.  I'm developing in a servlet/ejb
environment and I've got useful implementations of mock session and entity
beans going which allow me to test a lot of container dependent code without
the container.
 
However, one thing that concerns me is that my tests seem to expose the
implementations of the classes being tested.  I really like the XP practice
of test first by intention (code what you want not how to do it).  However,
when writing my mock object based tests I'm generally thinking about the
implementation as I write the test, as the expectations that I want to set
and verify depend on what I'm expecting the code to do internally.  Without
mock objects I tend to be more focused on externally verifiable consequences
of calling a method (which seem to be more intention based).  
 
I'm concerned this might make future refactoring more difficult because
refactoring may require me to change the expectations and verifications.
Hopefully, this won't be the case because generally I'm using mock objects
for other higher level objects such as other ejbs or framework classes which
should have well defined interfaces that won't change much.  
 
Also maybe I'm not exposing implementation.  I'm just making it easy to
verify things that I would otherwise have to verify externally, but which
might be difficult to setup in a unit test environment.  e.g. if a method
being tested creates a new entity bean as part of its implementation,
without mock objects, I would have to make some call as part of the test to
verify the entity was actually created.  With mock objects I just verify
that my method called my mock entity bean's create() method with the right
parameters.  Much simpler, faster and no database dependencies.
 
I was wondering if anyone else had any comments on the impact of mock
objects on the test first by intention practice.  Sorry for rambling!
 
Regards,
 
Martin Bayly
mar...@ho... <mailto:mar...@ho...> 

RE: [Mockobjects-java-users] Mock object tests expose class imple mentation details

[Clemmons, S. <sco...@fn...>]

> painful. In this case, do you find that the internal dependencies in your
mocks suggest
> possible refactorings in your production code? Does the maintenance

I think you might be right about this. Either that, or it's just that the
code that I've been writing tests for so far have been the entry-points (the
primary interfaces) to various subsystems. That is, the calls are typically
at a higher level and so have several cross-subsystem dependencies. It's
something I need to take a look at. 

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

Yes & no. I was able to generate ~ a hundered mock classes with mockmaker
within a very short time. It would've taken me much much longer without the
tool. However, I've found that I often have to customize the generated mock
classes slightly in order to be more useful with my tests. Therefore, if the
interface changes, and I have to regenerate a mock class, it may be painful.
I suspect, though, that most changes would be minor (adding or changing a
method or 2), and I can simply make modifications by hand. I'm trying to
minimize the effects of changes by this mock framework I've created
(somewhat as a facade). 

Thanks for you comments,

Scott

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