Hi forum,

I have a domain model which falls into several areas. One is dealing with a catalog (categories + product), one deals with items and another one with a third area of responsability.

I am currently following the idea to abstract the hibernate persistence implementation using some kind of a persistence manager (interface). Also there are several sub domain objects each managing its own area of responsibility. Therefore the catalog is accessed and modified using some kind of a catalog store and the items are managed by an item store etc.

Since the persistence manager is abstracted within the catalog store I have to test it on isolation. Therefore I mock the persistence manager and test if the appropriated interaction between the catalog store and the persistence manager takes places. Works fine and is fast. But the problem is testing the hibernate persistence manager. Since it is abstracted I have to test all domain objects against the hibernate persistence manager. Therefore the hibernate persistence manager TestCase class contains many, many test methods. Like adding and retrieve a product, adding and retrieve a category, adding and retrieve an item, add a product to a category, remove a category and check if the product is also removed and so on. I think you guess the meaning.

Since the TestCase gots so polluted I want to refactor it, to seperate the testing and maybe alter the design.

Does anyone have a suitable way to alter the design? How's your favorite design?


Thanks,

Martin (Kersten)

It seems to me that you're testing Hibernate, not your implmentation. If it's correct, then don't, there is already a test suite :)
I personnaly don't separate the abstract layer from hibernate is my tests. Actually building a good abstraction layer wo loosing Hibernate capabilities is almost imposible. You'll see Hibernate somewhere.

>It seems to me that you're testing Hibernate, not your implmentation.
Well I am not testing the hibernate implementation :-) As you mentioned, this would be a useless piece of wood. I am testing the mapping and all the other stuff.

The idea behind abstracting the hibernate stuff is to simplify other tasks and to keep things more interchangable. I altered the design to the following:

Again there is a IPersistenceManager and the catalog aspect has become ICatalogStore (both are interfaces).

Then on the persistence package a general implementation of ICatalogStore is placed. Since every persistence manager would be able to store an POJO like a Category element (the object which gets mapped to hibernate), this things are tested using a mocked persistence manager. But some abilities of ICatalogStore can't be implemented in a general way (such as making special selections over the stored tables) so this CatalogStore implementations are abstract.
The functionality which has to be implemented using advanced persistence manager functions (not reflected by the IPersistenceManager interface) are implemented within a HibernateCatalogStore class, which only implements the more complex functions. (currently there is only one but some others will be introduced soon (next use case of the catalog is requireing them)). The test case of HibernateCatalogStore tests everything usefull about the catalog using a real working hibernate backend. (No mock actually).

So I think this will suites us for some time.

packages:
*.domain
Category, Product, ICatalogStore
*.domain.persistence
CatalogStore, IPersistenceManager
*.domain.persistence.hibernate
HibernateCatalogStore, HibernatePersistenceManager

I hope I can keep the hibernate stuff out of the other packages, since hibernate is just a tiny implementation detail and should not show off other then the *.persistence.hibernate package.


Wish me luck :-)

Martin (Kersten)