Testing Batch Processes - Spring Batch - page 451

The testReadWithCustomer method is a good example of how to work with Mockito. You begin by
creating any data you need. In this case, you create the Customer object that your mock objects returns.
Then you tell Mockito what to return for each of the calls you care about: the call to
customerReader.read() and the two calls to tickerDao . In the listing, you set the customer id to be 5 and
tell Mockito to expect that 5 is the customer id passed to the two tickerDao calls. To tell this to Mockito,
you use the Mockito.when method to record what method call you care about. Only when these scenarios
occur does Mockito return what you specify in the thenReturn call.
With the mocks setup, you then execute the method you're testing ( reader.read() in this case). With
the results you receive from that method call, you can verify that your Statement object is built as you
expect based on the data it received.
How does this provide you with a safety net? Simple. Let's say that you change
CustomerStatementReader to pass the id of the account instead of the id of the customer to one of the
tickerDao calls. The test fails if this occurs, indicating to you that a change that is incompatible with your
expectations has occurred and needs to be addressed.
Unit tests are the foundation of a solid system. They not only provide the ability to make the
changes you need without fear, but also force you to keep your code concise and serve as executable
documentation for your system. However, you don't build a foundation just to look at it. You build on
top of it. In the next section, you expand your testing capabilities.
Integration Tests with Spring Classes
The previous section discussed unit tests and their benefits. Unit tests, however useful they are, do have
their limits. Integration testing takes your automated testing to the next level by bootstrapping your
application and running it with the same dependencies you tried so hard to extract previously. This
section looks at how to use Spring's integration test facilities to test interactions with various Spring
beans, databases, and finally batch resources.
General Integration Testing with Spring
Integration testing is about testing different pieces talking to each other. Does the DAO get wired
correctly, and is the Hibernate mapping correct so you can save the data you need? Does your service
retrieve the correct beans from a given factory? These and other cases are tested when you write
integration tests. But how do you do that without having to set up all the infrastructure and make sure
that infrastructure is available everywhere you want to run these tests? Luckily, you don't have to.
The two primary use cases for integration testing with the core Spring integration-testing facilities
are to test database interaction and to test Spring bean interaction (was a service wired up correctly, and
so on). To test this, let's look at the TickerDao you mocked in the unit tests previously
( CustomerStatementReader ). However, this time, you let Spring wire up TickerDao itself, and you use an
in-memory instance of HSQLDB 4 as your database so that you can execute the tests anywhere, anytime.
HSQLDB is a 100% Java implemented database that is great for integration testing because it's
lightweight to spool up an instance. To get started, let's look at how to configure your test environment.
4 It's important to note that using JDBC and switching database types can be difficult due to differences
in implemting SQL between databases. In this case, the only difference should be the create statements,
for which you can use separate scripts.