Simple Stub Creation with Mockito Partial Mocks

3 minute read
Published: 16 Jul, 2010

When testing code that interacts with lower layers, I often stub out the
lower layer to return objects to the code that I’m actually testing. I
mostly use stubs generated by a mocking framework, but I occasionally
come across cases where the stub needs to do something other than just
return a known object. Take the case of a
DAO that assigns a
generated identifier to a domain object. Here we see a service that
takes a name, creates a User object with it, persists the object and
returns the generated id to the caller.

How do we test that the service returns the correct id? The id will be
null by default because it’s a Long. At the very least we should make
sure it’s a non-null value, and we would prefer to assert that it’s
something specific. We can’t stub the domain object because the service
creates it. One option is to create a stub implementation of the DAO
that simply sets the object’s id to a known value. Assume that our DAO
interface looks like the one below.

While there aren’t too many methods, we really don’t care about anything
but persist, so it’d be nice if we only had to deal with the things we
do care about. This is where Mockito comes in.
Using the partial mocks
feature added in version 1.8.0, we can create an abstract class that
only implements the persist method, and let Mockito supply its useful
default implementations for the rest of the methods.

We now have an abstract stub for our DAO that will set the id of any
objects it persists to a 1 of type Long. You can obviously do something
more complicated if needed. Next we use Mockito to provide the rest of
the implementation.

The only thing different about creating a partial mock, is that you need
to call either thenCallRealMethod() or doCallRealMethod() to
indicate which method calls to delegate to the real object. The example
above uses doCallRealMethod() because persist has a void return
type. I’ve found this technique to be a very effective way to create
focused stubs that allow you to specify what you need to, and not worry
about the rest.

Update 2012-05-31

Someone pointed out in the now gone comments that this approach does not
work if the stub class needs to carry state. If this is the case for
you, you may want to consider a
fake. This may also
be an opportunity to refactor your code to make it easier to test the
desired behavior in isolation.

Published
by Marc Schwieterman
16 Jul, 2010
and tagged mockito and testing
using 565 words.