Best unit tests for Hibernate Entities

Question

Perhaps this is a naive question but I would like to just know experience from experienced people in this topic...

I am wondering what's the basic and best "things" that should be unit tested in Hibernate Entities. I explain myself a little better:

• Is it worth to test the simple CRUD form all Entities?
• Around here I have read that the developer should not rely on the constraints of the DB itself such as length, not null values, unique key, etc. Does it make sense to test all possible restriction defined within a DB Entity?
• Some other hints?

Another different question that came to my mind is, should I throw an exception in case of, for instance, null input values? Or this "layer/level" is too low to throw exceptions.

I really appreciate your time and experience in advance!

Answer 1

I assume you mean "entity" when mentioning a "POJO".

There is no need to test a entity or it's association. If you have faults there they will be presented to you when you test the DAO or service layer.

You should not throw any exception from entities directly. The Task of validation is done by validators e.g. Hibernate annotations or custom validator objects.

You should test every class and method that is part of the public API and used by clients that does something besides getting or setting a property and other trivial behavior. If it's a simple CRUD operation you still need to test if everything runs as expected (you may find some quirks on relationships etc. at this stage).

Answer 2

I not a TDD expert, just my personal opinion: I'm not compulsive about it, but I like to have at least one basic sanity per Entity, to see it actually arriving at the database - i.e. one simple method that saves and retrieves it back. Even more so if the entitiy contains some twist (relations, compound keys, etc). If I have a slightly more interesting scenario I might start directly with it -e.g. save a list and do complex query).

I don't test each and every constraint, but maybe it's a matter of taste/requirements. Regarding the null example, do you mean validation in the Entity's setter (e.g. setPrice())? Usually I wouldn't, I'd leave it to hibernate constraints. One reason is that my Entity might be used in other scenarios - e.g. read from client/file where data is intentionally missing, let the server complete that missing data, and save (if that client/file data is significantly messed up I'd use a dedicated DTO, but for simple cases I'd settle for the original object - though we have a philosophical argument about it in out team).

Good luck :)