Testing BusinessObjectFactories is an activity similar to database testing as 99% percent of code you should write in such classes implies database access.

In order to simplify test case writing our BusinessObjectFactoryTestCase abstract class extends DbUnit providing a pre-set environment. The DbUnit dependency implies many of the BusinessObjectFactories testing requires some knowledge of the DbUnit extension to JUnit.

A few steps are required to set your database testing environment:

Test are executed against an HSQL file based database named etc/test.db but you can change this configuration placing an hibernate.properties file in the default package. Read more for further details.

Create your own dataset file

Whatever of the following approaches you use to unit testing BusinessObjectFactories you should set up your own dataset in DbUnit style: if you have an existing and already populated database and you wish to use those datas for you unit test the easiest way to produce a dataset is through the DbUnit Maven Plugin and its export goal.

To ease your efforts in unit testing we set by default the following DbUnit Features when reading the default dataset:

  • case sensitive table names: depends on your hibernate dialect
  • qualified table names: depends on your hibernate dialect
  • escape pattern: depends on your hibernate dialect
  • column sensing: true

Unit testing extending BusinessObjectFactoryTestCase

Writing BusinessObjectFactory test cases can became as easy as inherit from BusinessObjectFactoryTestCase and implement the getDataSetFile method, as in the following example:

import net.smartlab.web.test.*;

public class MyFactoryTest extends BusinessObjectFactoryTestCase {

        protected String getDataSetFile() {
                return "myDbUnitDataSetFile";
        }

        public void testMyMethod {
                // your code here
        }

}

The previous example needs the presence of the file res/smartweb.jar.hcf to initialize the Hibernate SessionFactory, but if you need to initialize Hibernate with a different file you can simply re-implement the getFactoryConfiguration method, as follows:

import net.smartlab.web.test.*;

public class MyFactoryTest extends BusinessObjectFactoryTestCase {

        protected String getDataSetFile() {
                return "myDbUnitDataSetFile";
        }

        protected URL getFactoryConfiguration() throws Exception {
                return new File("your_hibernate_test_config_file").toURL();
        }

        public void testMyMethod {
                // your code here
        }

}

Since the 1.3 release our test extension library provides a mocked JNDI context allowing you to use the exact Hibernate configuration file you would be using on your production environment!

Unit testing with your own TestCase subclass

If for any reason you can't extend the BusinessObjectFactoryTestCase base class you can still take advantage of the testing library using the BusinessObjectFactoryTestSupport class, as in the following example:

import net.smartlab.web.test.*;
import junit.framework.*;

public class MyFactoryTest extends TestCase {

        protected void setUp() throws Exception {
                BusinessObjectFactoryTestSupport support = 
                                new BusinessObjectFactoryTestSupport("your_hibernate_test_config_file");
                BusinessObjectFactory.setConfigurationStrategy(support);
                super.setUp();
        }

        protected void tearDown() throws Exception {
                super.tearDown();
                BusinessObjectFactory.close();
        }

        public void testMyMethod {
                // your code here
        }

}

Obviously if you still need to setup a testing database you have to follow the DbUnit process for database testing with or without inheriting the DbUnit hierarchy, but this can became a complex process, exactly the process we are trying to hide through our classes!

Use a specific database server during test execution

By default unit tests are executed using your res/smartweb.jar.hcf Hibernate XML Configuration but against an HSQL file based database to provide a no-dependencies test environment. Sometimes running the tests against a specific database server is a must: stored procedures or database specific features are such a situation.

You can override the test environment database server by placing a properties file in the default package, practically overriding the default test environment configuration parameters. This property file must be named hibernate.properties and it's format is an Hibernate properties configuration file, as in the following example which, by the way, represents the default configuration:

hibernate.transaction.factory_class=org.hibernate.transaction.JDBCTransactionFactory
hibernate.current_session_context_class=thread
hibernate.dialect=org.hibernate.dialect.HSQLDialect
hibernate.connection.driver_class=org.hsqldb.jdbcDriver
hibernate.connection.url=jdbc:hsqldb:file:etc/out/test.db;shutdown=true
hibernate.connection.username=sa
hibernate.connection.password=

It's strongly recommended to not change the hibernate.transaction.factory_class and the hibernate.current_session_context_class properties default value.