Software Development Cross Solution - Index of - Free

why mock objects?
Q: These mock objects don’t seem to be doing anything I
couldn’t do myself. What are they buying me again?
A: Mock objects give you a way to create custom implementations
of interfaces without needing to actually write the code. Just look
at page 303. We needed three different variations of gift cards (if
you count the testInvalidGiftCard one). Two of them had different
behavior, not just different values. Without the mock objects we’d
have to implement that code ourselves. You could do it, but why?
Q: Why didn’t we use mock objects for the gift cards
themselves?
A: Well, two reasons. First, we’d have to introduce an interface
for the gift cards. Since we don’t have any behavioral variations it
really doesn’t make a lot of sense to put an interface here. Second,
all we’re really changing are the values it returns since it’s pretty
much a simple data object anyway. We can get that same result by
just instantiating a couple different gift cards at the beginning of our
test and set them to have the values we want. Mock objects (and the
required interface) would be overkill here.
Q: Speaking of interfaces, doesn’t this mean I’ll need an
interface at any point I’d want a mock object in my tests?
A: Yes—and truthfully sometimes you end up putting interfaces
in places that you really don’t ever intend on having more than one
implementation. It’s not ideal, but as long as you’re aware that you’re
adding the interface strictly for testing it’s not usually a big deal.
Generally the value you get from being able to unit-test effectively
with less test code makes it worth the trade-off.
Q: What’s that replay(...) method all about?
A: That’s how you tell the mock object that you’re done telling it
what’s about to happen. Once you call replay on the mock object it
will verify any method calls it gets after that. If it gets calls it wasn’t
expecting, in a different order, or with different arguments, it will throw
an exception (and thereby fail your test).
308 Chapter 8
Download at WoweBook.Com
Q: What about arguments...you say they’re compared with
Java’s equals( ) method?
A: Right—EasyMock tests the arguments the mock object gets
during execution against the ones you said it should get by using
the equals() method. This means you need to provide an
equals() method on classes you use for arguments to methods.
There are other comparison operators to help you deal with things
like arrays where the reference value is actually compared. Check
out the EasyMock docs (www.easymock.org/Documentation) for
more details.
Q: So we changed our design a pretty good bit to get all this
testing stuff going. The design feels.. upside-down. We’re telling
the OrderProcessor how to talk to the database now...
A: Yes, we are. This pattern is called dependency injection, and
it shows up in a lot of frameworks. Specifically the Spring Framework
is built on the concepts of dependency injection and inversion of
control. In general, dependency injection really supports testing—
particularly in cases where you need to hide something ugly like a
database or the network. It’s all about dependency management and
limiting how much of the system you need to be concerned about for
any given test.
Q:So do you need dependency injection to do good testing
or mock objects?
A: No. You could do a lot of what we did with the DBAccessor
by using a factory pattern that can create different kinds of
DBAccessors. However, some people feel that dependency
injection just feels cleaner. It does have an impact on your design,
and it does often mean adding an interface where you might not have
put one before, but those typically aren’t the parts of your design
that cause problems; it’s usually that part of the code that no one
bothered to look at because time was getting tight and the project
had to ship.