No need for manual deletion or an external script... just clear out the database in your test tear-down code. Here is our strategy (junit 4.x):
- Before all test cases (@BeforeClass): Generate a temporary directory randomly; create a database there, to be used by tests. - After each test case (@After): Drop all tables from the database - After all test cases (@AfterClass): Delete the temporary directory recursively. Jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron > Zeckoski > Sent: Wednesday, November 05, 2008 7:36 AM > To: Derby Discussion > Subject: Re: Embedded database which only stores data in memory? > > Thanks for the responses. > > To answer the earliest question above, we are just using Derby for > testing. There are a couple major missing features that make it > unsuitable for our database needs for production. We were using HSQLDB > for testing before but have found the lack or true transactions to be > a real issue (i.e. not catching TX problems in the tests). It is > extremely easy to setup and very very fast to start though so those > aspects of HSQLDB made it almost ideal. > > The suggestion about looking at the test cases seems reasonable so I > will do that shortly. > I am guessing you mean the stuff here right? > http://svn.apache.org/repos/asf/db/derby/code/trunk/java/testing/org/apach > e/derbyTesting/ > I had a little trouble figuring out the source structure so let me > know if this is the wrong stuff to be looking at. > > There is still a big issue no one in this thread has addressed yet and > that it the fact that derby creates files in the file system for each > test which we have to manually clear (or end up with tests that fail > because the derby database is already there and has unexpected data in > it). We are trying to drop derby in without changing our tests much > and so far I have been able to limit the changes to about 200 lines of > code (which already seems like a lot). Unfortunately, this is playing > havok with our CI server because we have to run an extra script now to > clear out the derby files before and after each build (just to be > sure). > I imagine there must be some option to disable the files creation. If > anyone knows how to do this please let me know. > The startup time is annoying but we can live with slower tests if they > are more reliable. > > Apologies if these are naive questions or I come off a bit strong. I > am under some time pressure here and vastly underestimated how long it > would take to switch from HSQLDB to Derby for testing. > Suggestions appreciated. > -AZ > > > On Wed, Nov 5, 2008 at 12:26 AM, Bryan Pendleton > <[EMAIL PROTECTED]> wrote: > >> Just to chime in here. We also use Derby for deployment, and are > having > >> the same grief with setup time for unit tests > > > > For what it's worth, Derby itself uses Derby in its own unit tests (of > > course), and overall we have quite good performance, I believe, in the > > Derby unit tests themselves. > > > > The Derby source tree contains extensive tests and test utilities, and > > is a great source of ideas about how to set up unit tests to work with > > a database efficiently. > > > > You might try exploring that body of testing code, and you might try > > contacting the folks on the derby-dev list to discuss the particular > > issues you're seeing. > > > > There's also an extensive section in the Derby wiki which discusses > > the technique behind the Derby unit testing harness. > > > > I believe that, with a certain amount of care, you should be able to > > achieve quite good performance for your unit testing using Derby. > > > > thanks, > > > > bryan > > > > > > -- > Aaron Zeckoski ([EMAIL PROTECTED]) > Senior Research Engineer - CARET - Cambridge University > [http://bugs.sakaiproject.org/confluence/display/~aaronz/] > Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
