Java Reference
In-Depth Information
<bean id="dataSourceInitializer"
class="org.springframework.jdbc.datasource.init.DataSourceInitializer">
<property name="dataSource" ref="dataSource"/>
<property name="enabled" value="true"/>
<property name="databasePopulator">
<bean class="org.springframework.jdbc.datasource.init.ResourceDatabasePopulator">
<property name="continueOnError" value="false"/>
<property name="ignoreFailedDrops" value="false"/>
<property name="sqlScriptEncoding" value="UTF-8"/>
<property name="scripts">
<list>
<value type="org.springframework.core.io.Resource">
${batch.schema.script}
</value>
</list>
</property>
</bean>
</property>
</bean>
</beans>
With
JobLauncherTestUtils
wired up, you use it to execute your step in the test's
testCarProcessingStep
method. On completion of executing the step, you verify two things: using the
regular JUnit assertions, you verify that the step completed successfully; and you verify that the file that
was created is the same as the one read in. Using JUnit to do something like this would be a very painful
exercise; but because file manipulation is at the core of the Spring Batch framework, Spring Batch
includes the ability to assert that two files are the same. The
AssertFile
utility class lets you compare two
files in their entirety or just the line counts of two files. This is a very helpful tool in your testing arsenal.
The only thing left that you could possibly test is the entire job. In the next section, you move to true
functional testing and test a batch job from end to end.
Testing a Job
Testing an entire job can be a daunting task. Some jobs, as you've seen, can be quite complex and
require setup that isn't easy to do. However, the benefits of being able to automate the execution and
result verification can't be ignored. Thus you're strongly encouraged to attempt to automate testing at
this level whenever possible. This section looks at how to use
JobLauncherTestUtils
to execute an entire
job for testing purposes.
In this example you use the same
carJob
as in the previous section, but this time you test the entire
job instead of the encompassing step. To do so, the
JobLauncherTestUtils
class is again your friend and
does all the hard work. Because you have only a single job configured in your context, all you need to do
to execute the job is call
JobLauncherTestUtils
'
launchJob()
method. In this case, you call the variant
that accepts a
JobParameters
object so you can pass in the locations of the input and output files you
wish to process.
The
launchJob()
method returns a JobExecution object. This, as you know from Chapter 4, gives you
access to just about everything that happened during the run of your job. You can check the
ExitStatus
of the job and each step, and you can verify the number of items read, processed, written, skipped, and
so on by each step. The list goes on. The importance of being able to programmatically test jobs at this
level with the ease that Spring Batch provides can't be overstated. Listing 12-20 shows the test method
for testing
carJob
as a whole.
