Hi Adam, I'm no transaction expert but how sure are we that starting a new transaction just before each test and rolling it back at the end won't work? From what I can gather Derby does actually alter the database prior to committing the transaction but it also creates log records that allow the changes to undone in case of a rollback.
I just tried it using the JUnitListener class to start and end a transaction and I can't see any obvious negative effects (aside from tests failing that relied on data created in previous tests). Regards Scott 2008/11/14 Adam Heath <[EMAIL PROTECTED]>: > David E Jones wrote: > >> [snip stuff about tests] > > On that note, it has become my primary non-paid-work concern, to make > the automated tests work out of the box. > > One idea that has been mentioned, is running each test in a transaction, > then rolling it back at the end. This won't work, for several reasons. > One, is that tests themselves may do multiple transaction things, even > going so far as calling services that spawn separate transactions. Two, > if the test calls commit, it actually won't, as it's running inside > another transaction started by the test container. > > Another idea that has been mentioned, is using the EntityAuditLog > feature. Since that only deals with single fields, it would need to be > extended. > > One I had this morning, is to use Entity Data xml. Whenever the new > entity is stored, save the old entity into a per-transaction based list. > When the transaction status changes, either throw it away, or commit > it. This would need to be extended to support deletes. > > And probably the simplest of all, is to save a copy of > runtime/data/derby, then after each test, shutdown stuff, and copy the > files back in. Preliminary testing shows that tarring up that dir, not > compressing, then deleting and untarring is the fastest. >
