There was an even better way to use HSQLDB
that was mentioned this weekend that I want to try out also. Basically,
you keep an HSQLDB database around as a snapshot of what you want your database
to look like. You can load this anyway you want. Then, before
running your tests, you just copy it, since it’s just a file! I
think this might be the fastest way to do it, but haven’t tried it
yet. Anyone tried that yet?
From: Rob
Keefer [mailto:rbkeefer@xxxxxxxxx]
Sent: Tuesday, August 08, 2006
2:41 PM
To: users@xxxxxxxxxx
Subject: Re: [cinjug-users] DbUnit
and Hibernate
-->
I just want to reinforce Ed's comment a bit...
Unit testing of DAOs is difficult because you'd like
to have reproducible tests that affect multiple tables, so after each test you
need to get the tables back into a known state. What hsqldb buys you is the
ability to do this easily.
On a project a few years back we had a crap-load of
DAO tests that took 16 hours to run. We had them organized into three
categories Select oriented query tests (so data wasn't altered at
all), CRUD oriented tests (each test was able to reset the data to a known
state after it completed), and then the transaction oriented tests. We tried a
number of schemes to update the database between transaction oriented tests,
but none worked very well.
So, even with some of the drawbacks this export to
hsqldb method has, it is easily the best method we have found to do these
kinds of tests, and we have the scars to show we've tried plenty of other
methods.
----- Original Message ----
From: Edward Sumerfield <esumerfd@xxxxxxxxx>
To: "users@xxxxxxxxxx" <users@xxxxxxxxxx>
Sent: Tuesday, August 8, 2006 1:24:18 PM
Subject: Re: [cinjug-users] DbUnit and Hibernate
DBUnit rocks. It gives you data exporting and importing to a few different
formats. I use Excel and XML format. I export data from an Oracle database and
import into hsqldb between each test. Very fast and fairly simple to use.
The toughest problem is managing load dependencies. Each exported table and row
must not break the foreign keys.
Oracle allows us to generate a list of tables in foreign key dependent order.
It doesn't solve the problem of self-referencing tables and the row sequence
though.
Additionally, since you are likley not exporting the entire database you may
miss some required dependencies so there is usually some data patching that is
required after the export to ensure that the data can be re-loaded correctly.
Make sure that you allow the export to include tables from a sub-dependent tree.
I have never been able to fix the dependencies for an entire schema.
On 8/8/06, twcrone@xxxxxxxxxxxxx <twcrone@xxxxxxxxxxxxx>
wrote:
In the past I have not built very good tests for my
Hibernate DAO's. Typically write a main method that tests the CRUD
operations but never put it somewhere that others can easily use
it or it can easily be run as a test suite. I have heard of something called
DBUNIT that I plan to look into. Any other suggestions?
BTW...NFJS conference this weekend was GREAT!!!
- Todd
--
Ed
|
|