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...>