Unit test with database

Question

I have an application that uses JPA 2 with Hibernate behind and for unit testing, I use HSQLDB in memory with Junit 4.11. HSQLDB is configured in a persistence.xml file in a META-INF folder.

My question is: How do I upload the clean database at the beginning of each test without having to manually call a bunch of "DELETE FROM BLA" or similar thing?

Currently I have problems within the methods @Before, a call something like this:

EntityManagerFactory emf = Persistence.createEntityManagerFactory(persistenceUnitName);

The EntityManagers produced are placed in a variable ThreadLocal, to ensure that each thread does not manipulate the EntityManagers from other threads.

In the methods @After I call a entityManager.clear().

However, the test is unreliable. Sometimes saved objects disappear for no apparent reason. And often the cache of Hibernate deceives me by showing objects that are not persisted, but seem to be, and with that I end up abusing the use of entityManager.clear() by precaution in places where this should not be necessary.

Someone has a better suggestion of some strategy to develop tests using HSQLDB in memory with Junit?

Answer 1

You have a EntityManager per thread, but all share the same database. If you run the tests concurrently, what one test does, can affect the other tests.

It is necessary to create the database in memory at each test.

I will quote a tutorial. Where he creates a file Hibernate.cfg.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
                                         "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
 <session-factory name="">
  <property name="hibernate.connection.driver_class">org.hsqldb.jdbcDriver</property>
  <property name="hibernate.connection.url">jdbc:hsqldb:mem:testdb;shutdown=false</property>
  <property name="hibernate.connection.username">sa</property><!-- default username -->
  <property name="hibernate.connection.password"/><!-- default password -->
  <property name="hibernate.connection.pool_size">10</property>
  <property name="hibernate.connection.autocommit">true</property>
  <property name="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</property>
  <property name="hibernate.hbm2ddl.auto">create-drop</property><!-- creates the tables from the entites automatically -->
  <property name="show_sql">true</property>
  <property name="dialect">org.hibernate.dialect.HSQLDialect</property>
  <mapping class="blog.hibernate.employee.Employee"/>
 </session-factory>
</hibernate-configuration>

And puts in the @BeforeClass of the test:

    @BeforeClass
    public void init() {
        config = new AnnotationConfiguration();
        config.configure(new File("hibernate.cfg.xml"));
            factory = config.buildSessionFactory();
            hibernateSession = factory.openSession();
        }

It’s a little old tutorial, but it should be very close to what you need to do in this version of Hibernate.

Answer 2

There’s a Hibernate property called hibernate.hbm2ddl.auto. When you’re in create-drop, will erase everything and recreate from scratch, ideal situation for your tests. What I usually do is have a base class that takes care of recreating the database at each test. Note that this happens with each test method, making the execution of your tests slow, but it is a price I think it is fair to pay. A good reference source is Hibernate’s own test suite. They use a different output, which is to recreate the database for each class. For this, they use some extensions of Junit, which may be too much for normal case.

Here are some examples that I use in personal projects, which may serve as inspiration:

META-INF/persistence.xml, with nothing else, except the property that erases and recreates the database.

Testwithentitymanager, base class for tests requiring a database.

Categoryservicetest, example of a class using Testwithentitymanager.

Answer 3

As already mentioned in other answers, Hibernate is able to create the database structure by adjusting the property hibernate.hbm2ddl.auto.

However, the use of this feature is unfeasible in somewhat more complex scenarios where, for example, there is a DBA in the process. There are many other issues in this regard, as we often need fine-tuning in the database: index creation, specific DBMS structures, data loads.

Solutions to this came in this year’s JPA 2.1 specification, which allow SQL scripts to be executed before or after Metadata database, or only scripts are executed. See some articles about the subject. Then it would be possible to define a script to create the necessary database structure at the beginning of each test.

Another approach to create a "Frankenstein" that mixes unit test and integration (I don’t want to get into the discussion here of what is what) is to use a test framework that allows some more adjustments, such as the Testng. This has an API very similar to Junit, but with some extra features:

• Specify dependency between tests or test group (influences the order of execution)
• Specify tests that may or may not be run in parallel
• Tests parameterized with a Data Provider

(For comparisons between Junit and Testng ver these links.)

Anyway, I made a brief presentation about Testng because it allows you to create something between a unit test and an integration test through the test clusters and the dependency between them.

To illustrate, someone could create a test @Test processarContratos() that depended on the test @Test incluirCliente() (which includes a customer) and test @TestincluirContrato(Contrato c) (which is linked to a Dataprovider and includes several contracts). Methods annotated with @BeforeSuite and @AfterSuite can be used to initialize and terminate the resources needed for the methods of a Test Suit.