Do you have the code for this that you can share? On Wed, Nov 5, 2008 at 7:31 PM, Jim Newsham <[EMAIL PROTECTED]> wrote: > > > 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/] > > > >
-- Aaron Zeckoski ([EMAIL PROTECTED]) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
