4
I’m developing a multi-layered, multi-module web project. For the persistence layer I am using JPA 2.1 and Hibernate 4.2 and for Junit 4 tests. In this architecture my project was divided into classes:
- Genericdao (interface);
- Genericdaoimpl (implementation);
- Entitydaoimpl (inherited from Genericdaoimpl);
- Genericservice (interface);
- Genericserviceimpl (implementation);
- Entityserviceimpl (inherited from Genericserviceimpl);
- Entity (POJO).
Naturally these entities have dependencies between themselves and maps one-to-one, one-to-Many, Many-to-one and Many-to-Many. I would like to test whether such entities are being persisted, with their respective relationships, correctly in the database.
I started developing these tests using a memory database (HSQLDB) provided by spring. I created a generic Genericservicetest test class that tests the methods of my Genericservicesimpl and extend to each specific entity, for example Entityservicetest. An Entity can be any object, user, account, city, country ...
Then when executing the Entityservicetest test class all Junit methods and annotations located in the Genericservicetest class are inherited and the test for this specific entity is performed.
To simulate the objects I used fixture Objects (fake Objects). But I’m having considerable work to test persistence between entities exactly on account of such relationships and concurrent execution of the testing methods. Type problems: not-null attributes that must be recovered from the database before saving the object that depends on it and objects that are being saved in a method have already been saved in previously executed methods.
My doubts are:
- There is a better way to test the persistence of such relationships ?
- It is common to test the persistence layer in this way ?
- I can say that this type of test is integration, since I am testing the integration between service layer and persistence layer ?
To avoid competition issues during persistence testing, you can run each test with a unique database transaction and rollback the transaction at the end of the test. The good thing is that this requires a very uncoupled design, the bad thing is that your current design may not be so uncoupled (these heritages light up a yellow light for me). A question: why are you testing dependency persistence? Don’t trust the stability of Hibernate? I use memory banks to test queries that may have been invalid after Refactoring and to test services.
– Caffé
As for the names, I know by "integration test" what tests the integration of the modules of a system, or the integration between systems. There are those who call it the tests of integrating the work of several developers (this one I do not like very much because it should be something natural and super frequent: integrate and test the work of all). Your tests for me are more like "service tests", where you invoke a service and let this call cross all layers of your system (in this case, service facade -> business -> database).
– Caffé
The goal is not to test Hibernate, but to ensure that JPA mappings were done correctly. Ensure that by persisting an object your relationships are being made. And that in the future another developer does not break the mappings that were made today. Thank you !
– Ciro Anacleto