When dealing with transactions in spring-test, it is basically rolled back after the test method. However, in the case of a test method that uses Spring Batch, a runtime error will occur. I will touch on this cause a little later, but if you use a transaction started outside Spring Batch internally, if you commit or rollback without knowing Spring Batch, batch state management may become strange. It seems to be.
However, the behavior of this Spring Batch gets in the way when running with spring-test. To solve this quickly, do as follows.
MapJobRepositoryFactoryBean b = new MapJobRepositoryFactoryBean();
b.setValidateTransactionState(false);
By setting false to setValidateTransactionState, the above transaction existence check will not be performed. The javadoc of the method has the following description.
* Flag to determine whether to check for an existing transaction when a
* JobExecution is created. Defaults to true because it is usually a
* mistake, and leads to problems with restartability and also to deadlocks
* in multi-threaded steps.
It is basically a mistake to use transactions outside Spring Batch, which can interfere with restartability and also cause deadlock in multithreaded steps. a. I don't think it's a problem in the case of unit tests.
That being said, I think it's okay to clear it with DBUnit or DbSetup every time. Of course it is disadvantageous in terms of speed.