Testing with mock objects - JUnit in Action - page 100

Yes! It's possible. The technique is called mock objects. Tim Mackinnon, Steve
Freeman, and Philip Craig first presented the mock objects concept at XP 2000. The
mock objects strategy allows you to unit test at the finest-possible level and develop
method by method, while providing you with unit tests for each method.

7.1 Introducing mock objects

Testing in isolation offers strong benefits, such as the ability to test code that has not
yet been written (as long as you at least have an interface to work with). In addition,
testing in isolation helps teams unit test one part of the code without waiting for all
the other parts.
The biggest advantage is the ability to write focused tests that test only a single
method, without side effects resulting from other objects being called from the
method under test. Small is beautiful. Writing small, focused tests is a tremendous
help; small tests are easy to understand and don't break when other parts of the code
are changed. Remember that one of the benefits of having a suite of unit tests is the
courage it gives you to refactor mercilessly—the unit tests act as a safeguard against
regression. If you have large tests and your refactoring introduces a bug, several tests
will fail; that result will tell you that there's a bug somewhere, but you won't know
where. With fine-grained tests, potentially fewer tests will be affected, and they'll pro-
vide precise messages that pinpoint the exact cause of the breakage.
Mock objects (or mocks for short) are perfectly suited for testing a portion of code
logic in isolation from the rest of the code. Mocks replace the objects with which your
methods under test collaborate, offering a layer of isolation. In that sense, they're sim-
ilar to stubs. But this is where the similarity ends, because mocks don't implement any
logic: they're empty shells that provide methods to let the tests control the behavior of
all the business methods of the faked class.
We discuss when to use mock objects in section 7.6 at the end of this chapter, after
we show them in action on some examples.

7.2 Unit testing with mock objects

In this section, we present an application and a test using mock objects. Imagine a
simple use case where you want to be able to make a bank transfer from one account
to another (figure 7.1 and listings 7.1 and 7.2).
The AccountService class offers services related to Account s and uses the
AccountManager to persist data to the database (using JDBC , for example). The service
that interests us is materialized by the AccountService.transfer method, which
makes the transfer. Without mocks, testing the AccountService.transfer behavior
would imply setting up a database, presetting it with test data, deploying the code
inside the container (Java EE application server, for example), and so forth. Although
this process is required to ensure the application works end to end, it's too much work
when you want to unit test only your code logic.