Best practice for testing Hibernate mappings

I am wondering what people have found their best practice to be for testing Hibernate mappings and queries ?

This cannot be done with Unit Testing, so my experience has been to write Integration Tests that solely tests the DAO layer downwards. This way I can fully test each Insert / Update / Delete / ReadQueries without testing the full end开发者_如何学JAVA-to-end solution.

Whenever the Integration test suite is run it will:-

1. Drop and re-create the database.
2. Run an import SQL script that contains a subset of data.
3. Run each test in a Transactional context that rolls back the transaction. Therefore it can be run multiple times as an independent test, or and as part of a suite, and the same result is returned as the database is always in a known state.

I never test against a different "in memory" database, as there is always an equivalent development database to test against.

I have never had the need to use DBUnit.

---

Never use DbUnit for this. It's way too much overhead for this level of testing.

Especially if you're using Spring in your app, check out the Spring Test Framework to help manage your data-access tests, particularly the transaction management features.

An "equivalent development database" is fine, but an in-memory H2 database will blow away anything else for speed. That's important because, while the unit/integration status of these tests may be contested, they're tests you want to run a lot, so they need to be as fast as possible.

So my DAO tests look like this:

1. Spring manages the SessionFactory and TransactionManager.
2. Spring handles all transactions for test methods.
3. Hibernate creates the current schema in an in-memory H2 database.
4. Test all the save, load, delete, and find methods, doing field-for-field comparison on before and after objects. (E.g. create object foo1, save it, load it as foo2, verify foo1 and foo2 contain identical values.)

Very lightweight and useful for quick feedback.

---

If you don't depend on proprietary rdbms features (triggers, stored procedures etc) then you can easily and fully test your DAOs using JUnit and an in memory database like HSQLDB. You'll need some rudimentary hibernate.cfg.xml emulation via a class (to initialize hibernate with HSQLDB, load the hbm.xml files you want) and then pass the provided datasource to your daos.

Works well and provides real value to the development lifecycle.

---

The way I do it is pretty similar with your own, with the exception of actually using in-memory data-bases, like HSQLDB. It's faster and more portable than having a real database configured (one that runs in a standalone server). It's true that for certain more advanced features HSQLDB won't work as it simply does not support them, but I've noticed that I hardly run into those when just integration testing my data access layer. However if this is the case, I like to use the "jar" version of mysql, which allows me to start a fully functional MYSql server from java, and shut it down when I'm done. This is not very practical as the jar file is quite big :

http://dev.mysql.com/doc/refman/5.0/en/connector-mxj-configuration-java-object.html

but it's still useful in some instances.