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

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

Thanks for contributing.

It's a bit hard to comment in the abstract -- could you post an example
of the sort of test you're worrying about? I have one suspicion which is
that you may be specifying too much detail in the test, which would make
maintenance difficult.

Mocks tend to push you towards testing the relationship between objects
so, yes, that could be regarded as exposing more of the internals. On
the other hand, if those internal interfaces are written at the
appropriate level, then you may not be giving away _too_ many secrets in
the test. The alternative is sometimes that you end up testing several
objects together, which makes refactoring harder because you have to
pull out the underlying object you want access to. Maybe this is till an
open topic. Again, having a cross-referencing IDE helps a lot.

Steve

----- Original Message -----
From: "Martin Bayly" <mar...@ho...>
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.