In a traditional dao pattern I can intercept all (crud) calls to from the database and so use dao mocking effectively to allow unit testing of my app logic in isolation from the db.

Can someone confirm that this is not possible once we use Hibernate and other orm (unless all the hibernate code lives inside the dao layer and we use dto's across the dao interface).

There is no longer a convenient mockable insert() or update() call being made on an interface, instead hibernate magically applies any dirty objects to the database in an arbitrary order on completion of the transaction.

----

Are there any good references on how - or whether to attempt - to unit test in light of orm?

One option might be to entirely isolate those components I want to unit test from the hibernate mapped domain model.
Express the api to those components in terms of dto's.
However this results in endless copying between the dto's and mapped objects.

----

Incidentally I see a lot of use of the word DAO in the forums - but for the most part these 'dao' are nothing but 'finders' - possibly it would be better to avoid "dao" in this case because the dao pattern usually includes insert/updat/delete.



JL

Not sure I understood what you mean, but you can have a hibernate.properties (and equivalents) for each environment. So, your unit test environment would point to one database (in-memory hsqldb perhaps), while the "staging" would point to a copy of your production database, and so on.

I understand that - but that is still not 'unit testing'.
We cannot isolate the application (business) logic from the persistance mechanism.

It's not unit testing in the normal sense of the word - it is database integration testing.

Basically, you want Hibernate to *not* use the database when you are testing? Unit testing database components (DAO) usually means making use of some database to make sure your units are working properly, ie: retrieving the information you asked. So, still not sure I understood what you want :-) It makes sense to use mocks for business components, but I can't think of a good case for not touching the database while testing DAO components.

You miunderstand.

I don't want to test the DAO - thats the point.

I want to unit test the business logic that sits above the dao (in a traditional dao pattern) by mocking the dao.

However because the hibernate (orm) pattern disolves away the insert/update/delete methods on the dao api (leaving just finders) there is nothing for me to use as a hook to mock.

Dude, I'm still not sure I understood what is wrong :-)



Hibernate doesn't forces you to use the insert/update/delete methods outside the DAO (ie: in your business components). I mean, you can certainly have something like:



So, your business keeps free from the implementation details of the DAO, enabling you to have N implementations of it. What am I missing? :-)

One can also do this outside the DAO layer
account.setBalance(100);
and the DAO layer will never get called but the change still gets applied to the db.
Which of course is what you expect if you use hibernate.

And of course I can go on bashing folks head to add redundant calls like save() below ...
Account account = accountDao.find(..);
account.setBalance(100);
accountDao.save(account);
But whats the point given that Hibernate is going to persist the change anyway - with or without the call to save()..

One cannot enforce layering (there is no layering) so genuine unit testing is only possible with dto's and the two-way conversion mentioned earlier.