tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcin Kwapisz" <mkwap...@zsk.p.lodz.pl>
Subject RE: Rollback transactions in unit testing
Date Thu, 02 Oct 2008 08:32:12 GMT
> Marcin,
> the strategy you suggest should also work and is especially good for
> prototyping or smaller projects.
> 
> In our case where we have a huge application with (>1.5 Mio LoC, > 1000
> EJBs, > 100 database tables with complex relationships) we cannot drop
> (or
> empty) and create tables in junit tests. This would heavily impact the
> development and testing.
> this is the reason why in such cases a rollback after a unit test
> instead of
> makes sense.
[Marcin Kwapisz] 
I know. That's why we run as many unit tests as it is possible between server startup and
shutdown.
But how to properly test transaction without committing it? (The link in Glauber Ferreira's
post concerns testing transactions).
Can I rollback transaction that has been committed? We do not use BMT in our project.

We tried to create unit test that in one transaction (CMT not BMT):
1. Creates initial set of data
2. Calls business method to modify/remove/(etc.) entities
3. Checks results.
And that was not a good idea. The results of unit tests depended on JPA provider (or JPA settings),
sometimes passed or sometimes not (the same test - that was really crazy). Manual flushing
did not helped. We had to split that one transaction into three to make unit tests work properly.

Regards
-- 
Marcin  Kwapisz
Samodzielny Zakład Sieci Komputerowych
Politechnika Łódzka




Mime
View raw message