views:

162

answers:

1

If I were to annotate my DAO integration test methods with @Transactional, Spring Test will happily rollback any changes to the database after each test methods completes. These seems extremely convenient, because I can load the test data once with a @BeforeClass method and all clean up is handled for me.

But I question whether this is a good practice because I'd be missed the opportunity to uncover failures that would occur during a commit. Whats the consensus on using transactions in dbunit integration tests of DAOs to help with clean up??

+1  A: 

This is perfectly fine. You will perform write operations on your unit-tests, and the DB will verify those operations. They won't be committed, but this last step would never fail because of business logic, so you should not worry about that.

espinchi
As it turns out, I have been very satisfied with this approach. In addition, loading the test data once per CUT rather than for ever test method saves a lot of time in integration testing. The only gotcha in all of this is that JUnit @BeforeClass (stupidly) requires the annotated method to be static. So I had to find another way to load the test data before each CUT....I wrote my own helper class for this.
HDave