How to use JUnit and Hibernate usefully?
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 开发者_如何学JAVAyou could give me some guides!
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
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.
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,
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.
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.
If you've created a DAO object, you can then send it some objects, call save, and then retrieve those objects and test the field values. That's very basic Hibernate testing.
Make sure you clean up your data though in your setup or teardown methods. If you save objects, delete them.
Best practices from Rails are to use a separate database for testing, one populated with test data. I wouldn't do this against a production database; if you have a development database for yourself that you can easily repopulate with data, just use that.
精彩评论