Generating Hibernate DAOs Junit test.

snichele · **Joined:** Fri Sep 16, 2005 7:51 am **Posts:** 25

Hi to all.

We are looking for some tools that can generate really simple JUnit test that can validate the adequation between the hbm files of our project and the database by testing our DAOs.

Our actual process is :
- Create 'business' Classes (Employee, Adress, aso...)
- Tag them with xdoclet tags ;
- Generate the hbm files ;
- Generate the database schema (hbm2ddl) and make the necessary update of the database (not always easy depending on the platform) ;
- Write some DAO (or use a generic DAO sometimes) ;
- and WRITE some unit test to test those DAO (which contains some CRUD tests).

And... writing the unit tests is boring !

Since simple operations are involved 90% of the time (read data, ok; try to update, ok; re-read data, ok; fetch a lazily fetched association, ok...)
we were wondering : "Why not GENERATE thoses tests ? Why not use a tool that can unit test those standards operation (or at least the greater part possible ) ?".

Since my researches on the web didn't poped up any result, I'm finally turning myself towards this helpfull community.

Thanks in advance for your help,

sn.

max · **Posted:** Mon Dec 05, 2005 9:27 am

Hi snichele,

I always wanted to add such functionallity (or similar) to the tools, but just haven't had the free cycles to do it.

Note, there are more than one way to skin a cat or validate hbm's and one of them is the new SchemaValidator in hibernate3 which validates some of the mappings between a hbm and an existing database.

SchemaValidator is a component in what I one day would like to have and call hbmlint (http://opensource2.atlassian.com/projec ... wse/HBX-95)

Another part of testing is (more or less random) data generation which datagen should do (http://opensource2.atlassian.com/projec ... se/HBX-215 and http://opensource2.atlassian.com/projec ... se/HBX-276)

And finally the issue you are talking about generation of basic junit test - again these can be fully automated or simply just a generation of a skeletion the developer can customize/extend for his or her needs.
This can be at different levels DAO, POJO, View etc., but I think to begin with just generating a few basic Pojo tests that validates that what one is doing with actual real code (instead of dynamic tests as the hbmlint) will be a good thing as it is more tangible and does not require a second layer.

As always contributions are welcome and the toolset is very extendible - just write a pojotest.vm and use <hbmtemplate template="pojotest.vm" filepattern="{package-name}/{class-name}HibernateTest.java"/> and you are "almost" there ;)

avartanian · **Joined:** Mon Jun 06, 2005 11:21 pm **Posts:** 10

I was thinking about the same kind of need. I was wondering what you might think of using an abstract TestCase class or even a generic abstract TestCase which could be trivially extended to create such tests. Here is just a quick sample of the sort of test I mean. This is just a really rought sketch, so the design isn't particularly well thought out:

Code:

public abstract class GenericDaoTest<ENTITY extends HasPrimaryKey<ID>, ID> extends TestCase {
   private GenericDao<ENTITY, ID> dao;
   private ENTITY e;
   protected abstract GenericDao<ENTITY, ID> makeGenericDao();
   protected abstract ENTITY makeEntity();
   protected void setUp() {
             dao = makeGenericDao();
             e = makeEntity();
        }
   protected void tearDown() {
              // ETC.
   }
   public void testDeleteAll() {   
              // ETC.
   }
   public void testFindById() {
              // ETC.
   }
   public void testDelete() {
              // ETC.
   }
   public void testMakePersistent() {
              // ETC.
   }
   public void testMakeTransient() {
                // ETC.
   }
}

My secondary concern however is to truly unit test my DAOs. There are many techniques for unit testing JDBC, including using a Golden Result technique to test generated SQL or mocking ResultSet or PreparedStatement. None of them seems to fit particularly well with Hibernate. Without some mechanism of truly unit testing, business logic tests could become coupled with Hibernate tests.

I'd greatly appreciate anyone's design ideas for solving these problems.