views:

194

answers:

5

I want to use JUnit to test Hibernate code such as insert, update, delete,.. method and transaction management.

But I don't know how to apply unit test for Hibernate usefully and what should I test with Hibernate.

How can I test DAO methods?

Hope that you could give me some guides!

+1  A: 

You can use a number of approaches, depending on your scenario

  • use an embedded database (HSQLDB) for your unit tests. Insert all requried data in @Before, and delete in @After. This is, however, not exactly a "unit" test, because it depends on some external preconditions.
  • you can mock your dao (using Mokcito, for example), so that it does not interfere with the database. This could be useful when testing your service layer and you don't care what is stored in the DB.
Bozho
+3  A: 

You can use DBUnit to test DAO Layer. Because you need data to test.
Example : DBUnit xml will insert dummy data to database which is described by you and then you can call assertEquals("myname", userDAO.findById(1).getName()); etc. After test you can delete dummy data with DBUnit. Check detail.

Documents
Hibernate testing with dbunit
DBUnit and Hibernate

javaloper
A: 

OK, a few points.
First of all, if you must test actual code that talks to the DB, use DBUnit for making your life easier, and it is recommended that you use HSQLDB, so that your tests will be able to setup their environment on runtime, without requiring a database already being installed and configured.

Second, if you don't have to talk with the DB, I'd use a general mocking library (be it EasyMock, JMock or Mockito, for example), and make the tests not really talk to a DB, which will usually make tests faster and simpler.

abyx
A: 

Personally I'm very wary about using embedded databases like HSQLDB with Hibernate and expecting that everything will work exactly the same when you move it to Oracle/MySQL/SQL server. Hibernate is too leaky an abstraction for that.

I have no experience with other frameworks besides JUnit. I find it does the job pretty well. Here's some things I always bear in mind:

  • Unit tests for database CRUD operations should never presuppose presence or absence of certain data. Everything that is inserted should also be deleted or rolled back.
  • Make sure to flush the underlying connection object. This will actually execute the cached statements, and set off any triggers on the data model.
Abject Orientation
A: 

Hi,

I use Chris Richardson's approach, described in POJO's in Action book

In-memory SQL database

Pros

  • No network traffic
  • No disc access
  • Useful to test the queries

Cons

  • Is its schema similar to the production database's schema ?

Named queries

Pros

  • Can be stored separately from the repository which allows you to test it without repositories

Cons

  • Does not work fine when using dinamic queries

Mock repositories

Pros

  • Reduces database accesses
  • Reduces the number of test cases

Cons

  • Needs to test queries against the database separately

DBUnit

Pros

  • It is a jUnit extension

Cons

  • You have to seu up an XML file that contains the expected values
  • Error prone if you miss a new mapped property

regards,

Arthur Ronald F D Garcia