Adam - I don't disagree with you often, but this is not the way to do this at all. I'd much rather have the db rollback the changes that were made and use data inserts than keep a collection of data files in place and hope that that always works - especially once you've upgraded the db, etc.
Data files and rollbacks will always work - that's definitely my vote. Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 ----- "Adam Heath" <[email protected]> wrote: > Scott Gray wrote: > > 2009/3/8 Adam Heath <[email protected]> > > > >> Scott Gray wrote: > >>> I haven't worked on it for a few weeks but I do have some code > that > >>> can track changes on the GenericDelegator and then reverse them > when > >>> requested. At the moment it makes the test independent at the > >>> component level, mostly because the was the easiest place to do > it. > >>> I've tested it by exporting the data from a fresh install, > running > >>> the tests, exporting again and comparing the differences and at > the > >>> moment the only data that gets left behind is anything coming > from > >>> async service calls. > >> My code doesn't require anything fancy. It just makes a backup > copy > >> of the entire data folder, and restores it between test runs. It > was > >> easy to do this, then try to have some filter that rolls back a > >> complex series of changes. > >> > > > > That approach is fine by me, except it limits you to testing with > derby only > > rather than a production type database. > > Not really, just alter the script to create a backup of the binary > production db, and stop/start it as well. Of course, that means > running as root or the same user as the other database, which may not > be feasible.
