Are the unit test case for JPA worthy? anyway it is just going to access DB, why do we need it?

Question

Are the unit test case for JPA worthy? anyway it is just going to access DB, why do we need it?

Answer 1

I've never done unit tests for JPA entities. I unit test the business logic where you'll either use JPA entities/qeries directly or you'll mock the queries.

Any reasonable IDE will validate a JPA model such that all the table and column names are correct. Once that's done, what more is there to do? The problem with unit testing queries is that you have to be able to expect certian data to validate the test and I've never been a fan of creating fake data just to pass a test.

Answer 2

You can use DbUnit to test database with JPA, if you have very complicated query that way you could test if it works with real db(dbunit uses hypersonic for tests). However it takes some time to set-up the data for test, so its much slower to write than unit test thats using mocks. it might be overkill, but you should try it and see how you like it. I think its not worth it.

Answer 3

My experience with unit testing the application I work on led me originally to create 'unit tests' accessing our ORM, requiring a database to be running in the background. Obviously this is a LOT more heavyweight than you really want a unit test to be and setup/teardown requires creating and deleting data through the ORM as well as getting access to a database, it's really an integration test but that's no reason not to do it. I do it as we have a lot of logic in the database and this is a pretty simple way to access it using code that everyone can understand, in your case I guess you need to ask if there is any of your own code you will actually test by doing this.

Answer 4

you could use an embedded Database e.g. HSQLDB or H2 Database and :

• test if the Annotation Mapping is "correct" (as in the SessionFactory can be started)
• use some "small" schema.sql to test constrains (e.g. String length, foreign key)
• take an early look at the SQL Statements to spot some weird mappings

and/or use an integration database (either remote or build locally with backups from production) and :

• make some performance or real data tests

Answer 5

Unit tests are usually proposed for

• things that you write (not libraries/frameworks)
• things that may break often
• things that fall into application logic code

JPA code

• was written by other people and not you
• if you use a good library (hibernate/toplink) the code is already mature
• persistence is NOT business logic

IMHO you should not do unit test for JPA. For extreme cases use DbUnit as already mentioned.

Answer 6

I disagree with most of the answers so far. For most enterprise applications, much of the business logic is embedded within database queries, most in JPQL if you're using JPA, and some can be quite complex. That is code that you're writing and therefore you should test it.

If the queries are simple -- no complex joins or criteria -- then it's not as much of a concern, but in my experience those apps are rare, and you're probably not needing something as powerful as JPA to build them. You'll pay in terms of scalability for apps that naively attempt to keep their persistence layer free of "business logic".

For most JPA apps, it's vital that the tests run outside of a container as a part of your normal, continuously-integrated build. The typical way to do that is with an in-memory database like HSQLDB or H2.

Java EE competes with frameworks like Rails and Django that expect the developer to unit test his code against a real database dedicated especially for that purpose. JPA developers should expect no less.