How Configure Hibernate for develop Test

Question

Hi every One, we are 9 programmer work on java Web application use hibernate framework, but we have problem by running(in run mode, debug mode) project each time we want test the project we must wait for Hibernate to create SessionFactory and all Relational Query! what should i do that Hibernate Work faster?

Answer 1

How long does it take? I know it takes sometime but not that long. I don't see what you can do here if takes that much time.

Are you sure its the sessionfactory which is taking time and not something else in your application which is getting initialized at startup?

You can use unit tests for testing some part of code so less startup of the whole application.

Answer 2

Can you elaborate on the time it takes :

• It is once, or per test ?
• How long exactly are you talking about ?
• What is the Hibernate load ? (number of tables, or better total number of columns etc...)

Depending on your answers, several directions could be investigated, such as actually reducing (a few percent only I'm afraid) that time through clever configuration ...

But my initial guess would be that you might have a more clever move with actually not instanciating Hibernate for your test. That would solve everything, wouldn't it ? Although it may seem silly said like that, this is how we proceed :

• We split our JUnit test in several categories (based on projects, or source directory, or otherwise ...). Each is runnable separately (ask if needed).
• We call one test category IntegrationTesting, it need to have access to expensive (slow or otherwise) ressources such as the database, foreign web-services or other software started (possibly with no concurrent access), threading, IO, JMS, DLLs, costly licences, x509 certificates, load-mesurement, timeouts ... Setting up these tests is more complex, might not be doable from every workstation, and executing them take much more time. Each time a developper is working on such a feature, he runs the appropriate test (or more) often, and accepts the delay. Our automatic build runs all of them every day, that's how we ensure regressions detection.
• We call one test category UnitTesting. It requires no access to expensive ressources, so for example it doesn't trigger Hibernate initialization. Each developper executes these tests all the time, and they are lighting fast (a few seconds would be for a big project) ! We don't bother selecting only one of them...

True, this organization of tests impacts the application design and code, but this is also prescribed by current best-practices, so we enjoy many advantages from it. Example :

• BEFORE : a business algorithm calling dao for database communication could be as follow :
  1. one = dao.readOne()
  2. a = do algo A
  3. two = dao.readTwo()
  4. b = do algo B
  5. if (b) dao.save(one, two, a, b)
• AFTER : We split more in different classes or methods the differing responsibilities :
  1. one = dao.readOne()
  2. two = dao.readTwo()
  3. (a,b) = do algo AB(one,two)
     • a = do algo A(one)
     • b = do algo B(two)
  4. if (b) dao.save(one, two, a, b)

Before, we couldn't test "do algo AB" independently from the database, because it was part of a global process that included database access (even more, the access was intermingled with the logic).

After, the "do algo AB" is easy to test in UnitTesting.

We also find many advantages in having read-only database operations first, processing, then write-only database operations.

1. JUnit performance : as said before.

   Note that the Daos testing can be done with IntegrationTesting. Actually, in our project, we focus JUnit on UnitTesting, and have few IntegrationTests, we test most of them directly from the UI... The IntegrationTesting ROI is not as good ;-)

2. Short and focused transactions : We can have two transactions (and Sessions) for example, enjoying Hibernate identity guaranty for complex read-only phase. When the algorithm modifies the entities, no implicit update is triggered by Hibernate (early developpers in our project had no clue this could happen !). If the algorithm decides not to update the database, no time has been spend on sending data to the database, no need to cancel that transaction ...

3. Reusability of the algorithms : we have many cases where the corresponding data for on computation have already been loaded by an algorithm that is called before, so it is a waste to reload it from the database. Also, reloading might carry differing data, resulting in fragile computations.

4. ... Others I can't remember right now ;-)

The Junit.org site has many great ressources for testing strategies. I also loved the excellent Rainsberger book ( http://www.manning.com/rainsberger/), I definitely recommend it for any project that used automated testing and has more than one developper. :-)