I am trying to build a simple framework using JUnit for testing classes that use Hibernate to persist objects.

These tests will typically create a few objects, persist them to the database, read them back, update, etc. At the end of the test, I want all the objects I added out of the database.

My strategy for doing this is to place each object created in a list, and then iterate the list in reverse order in the tearDown() method and delete each object.

This strategy mostly works except for this: the unit tests may themselves want to test deletion, and then verify that the deleted object no longer exists in the database. However, if the test fails, I still want the tearDown() method to attempt to delete the object, even though it may no longer exist.

My first approach was to wrap each deletion in a try-catch block to catch the exceptions that may occur when the object has already been deleted, and just move on down the list.

But then I read "Chapter 20 - Best Practices" which tells me it's an awfully good idea not to treat exceptions as recoverable.

So my question is first whether what I am doing is really unsafe.
My second question is whether there's a method that will delete an object only if it exists, or whether I should just bite the bullet and try to get() the object (not load() which would throw) and only delete it if it's available.

You could use get() for you purposes but you could also consider using dbUnit as it wil populate the database and can be used to check the state is correct after making changes to the database.

Hi,

My practice for unit testing is similar to yours. However, instead of using hibernate to remove objects, I just use straight sql to remove the objects. Most of my tables have a field called "update_source", which in the case of a unit test is UT. So at the end of my tests, i just issue a bunch of prepared statements like:
"delete from x where x.update_source='UT'

Works pretty well so far.

James

I am setting up DBunit to test my HIbernate stuff. Should I have JDBC connection object somehow returned from my DAO in order to have DBUnit get the connection?

Hi,

a crude-but-workable hack I used for a couple of applications was using negative IDs for unit test / temporary data, and positive IDs for my "normal" interactive test data. My Db-Unit Tests have a common super class with a tear-down method that just goes through all tables and deletes all temporary data with ID < 0.

Now, these were non-Hibernate applications, but I'm sure Hibernate can be tweaked to support a similar schema if that's what you want.

HTH =) Phouk