Why was integration tests using Spring Test framework designed to need @Transactional annotation in the @Test method by default?

Question

Based on the documentation on Spring testing: https://docs.spring.io/spring-framework/reference/testing/testcontext-framework/tx.html#testcontext-tx-enabling-transactions

Annotating a test method with @Transactional causes the test to be run within a transaction that is, by default, automatically rolled back after completion of the test. If a test class is annotated with @Transactional, each test method within that class hierarchy runs within a transaction. Test methods that are not annotated with @Transactional (at the class or method level) are not run within a transaction.

@Transactional is needed in an integration test using Spring Test. This approach is good in that after the test all the update will be rolled back.

Question: But the approach of adding @Transactional annotation to each test method doesn't test the persisted result. is this approach a true integration test at all?

• Thomas Owens: How do you define "integration test"? If your test includes more than 1 component, then I don't see how it wouldn't be an integration test, regardless of whether there are transactions to roll back changes.
• Kilian Foth: The entire point of transactions is that you can make DB changes as if they were real and observe the system response, without them actually being real. If you mistrust your DB's transaction subsystem, then a project integration test is not the place to verify it.
• Rui: @ThomasOwens typically a DAO class can be tested by means of adding @Transactional annotation to the @Test method, but in this case is the test an integration test since the test is testing only one class, i.e. the DAO class
• Thomas Owens: I'm really not following. Whether or not you use transactional annotations is independent of whether or not it's an integration test.
• Rui: @ThomasOwens according to my understanding, the integration test on a DAO class should be to verify the updated result in the database, i.e. the integration of application and database system

Answer 1

But the approach of adding @Transactional annotation to each test method doesn't test the persisted result. is this approach a true integration test at all?

Testing the persisted result after the @Transactional annotation rolls the changes back doesn’t test your custom changes. That would test the @Transactional annotation and the roll back system. That was already tested by Spring and your DB respectively. Those tests don't need to be redone here.

In a way they can't be done here since many things can talk to the DB. There's no guaranty that the DB will be back in the same state as before your transaction since other updates may have happened by now. A rolled back transaction only promises that your changes are not applied. Not that nothing else changed.

• Rui: thanks a lot for your answer. what did you mean "Those tests don't need to be redone here"? I previously wrote such integration test by retrieving the persisted result from the database and then verify the newly retrieved data, but wouldn't my approach be more viable?
• candied_orange: @Rui better now?