It is very difficult to "unit" test the spring batch job because there is so much interaction with external resources like databases or files, etc. The approach that I have has two levels:
Individual methods in touchplanes are checked as usual, I just call the methods directly from the JUnit test with regular mocks or stubs.
Secondly, I run the package from the JUnit test, calling the main method directly, with all the necessary infrastructure. For my batch jobs, I need a database and some input files. My JUnit test copies all the necessary files for this test to the temp directory (I use maven, usually target/it ), along with the database (I have a copy of my MySQL database saved in HSQLDB format). Then I call Main.main() directly with the correct parameters, let the package run and then check the results, check if the correct files were created, the database was changed correctly, etc.
This has several advantages as a way of working.
- I can run these tests from Eclipse, so I shorten the debugging cycle, because I do not need to create a complete package every time to check it.
- They fit easily into the assembly, I just include them in the failover plugin in maven.
With a few warnings:
You will need to run the main method in the SecurityManager. If your main calls are System.exit (), you do not want the JVM to stop. For an example SecurityManager, see org.junit.tests.running.core.MainRunner . It is called:
Integer exitValue = new MainRunner().runWithCheckForSystemExit(new Runnable() { public void run() { Main.main(new String[] {}); } });
Using the above, you can argue that the package calls System.exit () with the correct values on failure, which also allows you to check the failure conditions.
Secondly, you can make many settings from the JUnit test, but you cannot do all this, so if, for example, you need an FTP server, I usually start it from maven, and not from JUnit, to fail-safe plug-ins. Sometimes it can be a little difficult.