db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Newsham" <jnews...@referentia.com>
Subject RE: Embedded database which only stores data in memory?
Date Wed, 05 Nov 2008 19:31:48 GMT


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: azeckoski@gmail.com [mailto:azeckoski@gmail.com] 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
> <bpendleton@amberpoint.com> 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 (aaronz@vt.edu)
> Senior Research Engineer - CARET - Cambridge University
> [http://bugs.sakaiproject.org/confluence/display/~aaronz/]
> Sakai Fellow - [http://aaronz-sakai.blogspot.com/]




Mime
View raw message