Hi, Muhammad. Thanks for dropping by; your questions are good ones.
Post by Muhammad IchsanA have dao (data access object) implementation with hibernate. In
service layer the dao passes the domain object to be processed.
Sometimes service methods try to get properties of the domain object
managed by the hibernate. In some case hibernate may throw exception
because session has been closed.
In short, I just want to make sure the behaviour of the hibernate
object in data layer not throw any exception. This is what I call
success in service layer.
- test the service layer no matter the daos are.
- test the behaviour of hibernate object.
I think this is gonna be complecated test. I guess.
If you want to stick with your current architectural patterns, the
Hibernate unit tests will have to exercise the object in the same way
the higher layers will to make sure no exceptions will be thrown.
However, I'd recommend that you change your approach in a few ways.
First see if you can keep the Hibernate session open. If we're talking a
web application here, this means closing the session after you transmit
the response. Then there's no risk of unexpected exceptions, and keeping
the session open for a few extra milliseconds is a small price to pay.
It also sounds like you are implementing a 3-tier architecture in
layers. In my experience, that often leads to Martin Fowler's "Anemic
Domain Model" anti-pattern, and it's hugely inefficient. In a multi-tier
architecture you're obliged to copy your data repeatedly because you're
crossing JVM boundaries all the time. But if you just turn the tiers
into layers, you end up with a huge amount of unnecessary copying.
Instead, consider eliminating the DAO layer, using Hibernate to map your
domain objects directly to the database, and moving a lot of the service
layer code into the domain objects themselves. You'll end up with a much
cleaner model, one that will be easier to test.
Third, rather than separating things out via mocks, I'd suggest you test
things together when speed allows it. One way to do that with Hibernate
is to use an in-RAM database like Hypersonic for most of your tests.
Another is to make Hibernate itself pluggable: make a thin persistence
interface, then make a Hibernate implementation and one that just stores
your "persistent" objects in HashMaps for the duration of the tests.
Either approach is fast, and either approach lets you easily try all of
your unit tests against particular databases if you'd like to. Of
course, you'll still need unit tests for the Hibernate mappings, and I
prefer to do those against a real database.
Hoping that helps,
William
To Post a message, send it to: ***@eGroups.com
To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com
ad-free courtesy of objectmentor.com