1 Reply Latest reply on Aug 17, 2010 1:03 PM by dan.j.allen

    Transaction rollback after a test is run

    pmckinney7

      First of all I would like to say that I'm excited by the Arquillian project and am very appreciative with what I have been able to do with Arquilllian so far.

       

      My question though; is there a way to have a JUnit test method start a transaction and then at the end of that test method perform a transaction rollback?  In the past Arquillian release notes mentioned of possibly implementing a @TransactionAttribute annotation to add support for transactions in tests but I have not heard anything further.  Are there still plans to make tests transactional and if so would we be able to rollback at the end of the transaction, though I guess an exception could be thrown to force this to occur?

       

      Having the ability to do this would really help in some of the database releated tests in which it is difficult to load even a small subset of data, using DbUnit, due to circular references and integregy contraints (Oracle).

       

      Any information or insight would be appreciated.  Thanks

        • 1. Re: Transaction rollback after a test is run
          dan.j.allen

          This was discussed at length a few weeks ago (I forget where now, possibly IRC). We concluded that being able to intercept test methods for the purpose of declaring a transaction rollback is a very flimsy edge case. A far more robust approach is to inject the UserTransaction or EJBContext and invoke the method to mark the transaction for rollback.

           

          But you should only be doing that if you are testing that the transaction operations can be rolled back (for instance, XA transaction atomicity). You should not be rolling back the transaction to forgo modifying a production (or test) database. The reason is, rolling back a transaction often causes the writes to be bypassed altogether (a typical optimization of write-behind frameworks like JPA). In this case, your test is not able to validate that the writes will actually succeed if attempted, and hence you have a meaningless test. If you are testing database updates, you should let the update complete, commit the transaction, then in a separate transaction (even a separate entity manager), make sure the data is there.

           

          So be careful what you wish for

          1 of 1 people found this helpful