one of the reasons Dependency Injection frameworks like Spring have taken off—they allow you to inject
your proxy objects without modifying any code.
The second form of mocking is to remap the class file in the class loader. The mocking framework
JMockit is the only framework I'm aware of that currently exploits this ability for mock objects. The
concept is relatively new (because JDK 1.5 although JMockit supports JDK 1.4 thru other means as well)
and is provided by the new java.lang.instrument.Insturmentation interface. You tell the classloader to
remap the reference to the class file it loads. So, let's say you have a class MyDependency with the
corresponding .class file MyDependency.class , and you want to mock it to use MyMock instead. By using
this type of mock objects, you actually remap in the classloader the reference from MyDependency to
MyMock.class . This allows you to mock objects that are created by using the new operator. Although this
approach provides more power than the proxy-object approach because of its ability to inject literally
any implementation into the classloader, it's also harder and more confusing to get going given the
knowledge of classloaders you need in order to be able to use all its features.
Mockito is a popular proxy-based mock-object framework that provides a large amount of flexibility
coupled with an expressive syntax. It allows you to create easy-to-understand unit tests with relative
ease. Let's take a look.
Around 2008, with EasyMock as the dominant mocking framework, a couple of guys took a look at the
framework and asked some questions. EasyMock is a proxy-based mock-object framework that requires
the model, record, play, and verify. First you record the behavior you need. Then you execute the
functionality under test, and finally you verify all the executions that you previously recorded. However,
why do you need to define all the possible interactions for an object to go through? And why do you need
to confirm that all the interactions occurred? Mockito allows you to mock the behaviors you care about
and verify only the behaviors that matter. In this section you look at some of the functionality available
with Mockito and use it to test Spring Batch components.
Although JUnit is included by default any time you use Maven as your build system, for you to use
Mockito, you need to add its dependency. Listing 12-3 shows the dependency required for Mockito.
Listing 12-3. Maven Dependency for Mocktio
To see how Mockito works, let's look at one of the classes you developed for the statement job in
Chapter 10. The CustomerStatementReader you created to build the Statement object is a prime candidate
to use mock objects, with its dependencies on an external ItemReader as well as a DAO. To refresh your
memory, Listing 12-4 shows the code from that ItemReader.
Listing 12-4. CustomerStatementReader