Are the unit test case for JPA worthy? anyway it is just going to access DB, why do we need it?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Are the unit test case for JPA worthy? anyway it is just going to access DB, why do we need it?
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.