# unitils.properties

# Assign the SpringDataSourceFactory DataSource.
org.unitils.database.config.DataSourceFactory.implClassName= com.tek.design.unitils.SpringDataSourceFactory

Write your SpringDataSourceFactory and implement both DataSourceFactory and springs ApplicationContextAware interfaces. Then in the init method you will be able to fetch your spring DataSource bean from the application context using a service look up. Not ideal, but until future releases it will do just fine.

package com.tek.design.unitils;

import java.util.Properties;
import javax.sql.DataSource;

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.unitils.database.config.DataSourceFactory;

/**
 *
 * Unitil's provides a way to override the default DataSourceFactory.  This class provides facility to
 * spring wire in the same datasource used by your ORM by fetching it from the ApplicationContext.
 *
 * Use the org.unitils.database.config.DataSourceFactory.implClassName property to supply this factory to unitils.
 *
 */
public class SpringDataSourceFactory implements DataSourceFactory, ApplicationContextAware {

    private static ApplicationContext appContext;

    private DataSource dataSource;

    @Override
    public DataSource createDataSource() {
        return this.dataSource;
    }

    @Override
    public void init(Properties arg0) {

        if (null == this.dataSource) {
            String dataSourceBeanName = "TekDesignDataSource";
            this.dataSource = (DataSource) appContext.getBean(dataSourceBeanName);
            if (this.dataSource == null) {
                throw new SpringBeanLookupException(DataSource.class, "Cant find bean named " + dataSourceName);
            }
        }

    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        appContext = applicationContext;

    }

}

Full unitils properties file:

# unitils.properties

# Provide a CSV of all used database schemas. ie schema1,schema2.
# The first schema name is the default one.
# If no schema name is specified in a dbunit data set the default one is used.
#
# A schema names are case sensitive when surrounded by database identifier quotes (e.g. “” for oracle)
#
# Example unitils description using a schema
#
#<dataset xmlns:frt=”FRUIT”>
#   <frt:APPLE NAME=”COX”
#                           DESCRIPTION=”[null]” />
#</dataset>
#
database.schemaNames=fruit,veg

# This property specifies the underlying DBMS implementation. Supported values are ‘oracle’, ‘db2′, ‘mysql’, ‘hsqldb’,
# ‘postgresql’, ‘derby’ and ‘mssql’. The value of this property defines which vendor specific implementations of
# DbSupport and ConstraintsDisabler are chosen.
database.dialect=oracle

# The dao tests often share the same data in the setup files, so its important to
# rollback between tests otherwise constraints will be violated.
DatabaseModule.Transactional.value.default=rollback

# Assign the SpringDataSourceFactory DataSource.
org.unitils.database.config.DataSourceFactory.implClassName=
com.tek.design.unitils.SpringDataSourceFactory

                          

Sometimes JPA entity classes get hijacked.

Say for instance you have a need to pass entity classes to another system, via JAXB.  Its possible to use DTO objects for the transfer or you could just annotate the the entity classes.  In the example below, I wanted to fetch something from a database via JPA and write it into gigaspaces.  It soon gets messy your Entity classes start to become a hub in the middle of your application with things dipping into some of the classes and annotating them and throwing them here and there.

Lets look at a simple one from my example system.  This one is only used by gigaspaces and hibernate, it could get much messier than this if I chose to add one or two more technologies.  I am deliberately leaving the imports in the examples so you can see where it all came from.

import com.gigaspaces.annotation.pojo.SpaceClass;
import com.gigaspaces.annotation.pojo.SpaceId;
import com.gigaspaces.annotation.pojo.SpaceRouting;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.persistence.Transient;

@Entity
@Table(name = "HOUSE")
@SpaceClass
public class MessyHouse {

    private String id;
    private String name;
    private String address;
    private String pageId;

    public MessyHouse() {
    }  

    @SpaceRouting
    @Transient
    public String getPageId() {
    return pageId;
    }

    public void setPageId(String pageId) {
    this.pageId = pageId;
    }

    @Id
    @GeneratedValue
    @Column(name = "HOUSE_ID")
    @SpaceId(autoGenerate = false)
    public String getId() {
    return id;
    }

    public void setId(String id) {
    this.id = id;
    }

    public String getAddress() {
    return address;
    }

    public void setAddress(String address) {
    this.address = address;
    }

    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }
}

Some things I dislike about what I have done here

• See the block I have marked below SpaceRouting.  In this class I wanted to change the Gigaspace routing strategy, so I have a method that has nothing to do with the persistence.  Does adding annotations break the “A class should have only one responsibility” design goal?  No perhaps not, but adding a whole method that is a Gigaspace concern does.
• As you add more and more annotations from different technologies things get messy very quickly.
• I have a JPA based DAO that uses this class.  I also have a set of gigaspace processing units that use this class.  Both systems are impinging their own design requirements on the class.  At the moment they are deceptively similar.  Gigaspace insists upon a default constructor, and getters and setters for all fields you wish to persist.  Hibernate is not quite as strict.  What if Gigaspaces relaxes that rule later and allows you to annotate the fields instead?  Or perhaps added some other design restriction.  Its unclear by looking at the class what things are there for hibernates soft contract and what gigaspace is insisting upon.
• If my gigaspace experiment gets big (not that likely!).  I might want to split off the gigaspace into its own project and use it as a component.  Ah! so what about the MessyHouse class then?  Where should that live?  Indeed its going to be in the wrong project wherever I decide to keep it.

This is one solution that I put to you.  Create a class for the gigaspace fields, and compose a House class into it.  With composition we can neatly separate the concerns.  Well almost.  Gigaspace may store these objects and need to restore them at some point.  I believe to do that it creates House, and populates it.  Then it creates GsHouseWrapper and injects House into it.  To do that you need a setter for the house but at least we have a class with Gigaspace design constraints and another with Hibernate peculiarities.  Check out the classes below and let me know what you make of the design.  Are there alternatives?

Also, currently there is a problem with the design below. The delegation methods fail with an exception. i.e house.setId(id); fails when writing the object to the space. I need to submit a ticket with the Gigaspace crew to figure out why.

The refactored classes.

package javapuzzlers.compose;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name = "HOUSE")
public class House {

    private String id;
    private String name;
    private String address;

    public House() {
    }

    @Id
    @GeneratedValue
    @Column(name = "HOUSE_ID")
    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

package javapuzzlers.compose;

import com.gigaspaces.annotation.pojo.SpaceClass;
import com.gigaspaces.annotation.pojo.SpaceId;
import com.gigaspaces.annotation.pojo.SpaceRouting;

@SpaceClass
public class GsHouseWrapper {

    private House house;
    private String pageId;

    public GsHouseWrapper() {
    }

    public GsHouseWrapper(House house) {
      this.house = house;
    }

    @SpaceId(autoGenerate = false)
    public String getId() {
        return house.getId();
    }

    public void setId(String id) {
        house.setId(id);
    }

    @SpaceRouting
    public String getPageId() {
        return pageId;
    }

    public void setPageId(String pageId) {
        this.pageId = pageId;
    }

    public GsHouseWrapper(House house) {
        this.house = house;
    }

    public String getName() {
        return house.getName();
    }

    public String getAddress() {
        return house.getAddress();
    }
}

                          

In the main though I would use it should the need arise.

                          

One way to test a DAO method is to provide a data fixture written in java. This will provide a populated in memory database and immutable objects that contain the data inserted.  The immutable objects can then be used later for making assertions against the data returned from the DAO method under test.  This describes a similar pattern: Unit Test with in memory Db.  I wrote a more modern version using the EntityManager instead of Jdbc and SpringTests with Junit 4 but the principle is the same.

There are some rules for my data fixture:

• The data must not be inserted using the DAO as this means your relying on the DAO under test.  I used the entity manager providing direct insert statements and just executed the sql.
• The data inserted must be driven from some immutable holder objects that encapsulate that data.  This provides a robust test and some handy containers that are used later in the test.  This also means that the test has no need whatsoever to know anything about the data!  It just needs to make assertions that the data holders contain the same data as the model returned from the dao.
• Assert that default values are not used.  I have seen bugs because ’0′ was used as data in long type identifiers, then it turns out the code never set the variable.  My data holders validate their invariants.
• The fixture should be responsible for stringing together primary and foreign keys, avoiding problems with uniqueness etc.  I.e the fixture is aware of the database requirements.
• The fixture should allow for several generations of itself to be created.  Thus from the test, several rows of data and the associated graph can be created to provide a rich enough set.  Rich enough to provide good data coverage without being complex or slow.
• Finally labels, names and other data should be identifiable, this makes it easier to debug if required.

So with careful thought, use of the builder pattern for the main fixture, immutable object design and a hierarchy of data and object creation I arrive at the finished product.  The design is strong, the test works and it satisfies the above requirements, but I am not happy.

It took too long to hand craft all this code.  The fixture is big although easy to understand.  There has to be a better way.  So I look for an alternative.  What I want is something that provides the above as far as possible but lighter.  I envisaged, something where the data is configurable and you don’t have to write the complex fixture at all.

Unitils a possible shortcut

Quoting from the Unitils site: Unit tests for the database layer can be extremely valuable when building enterprise applications, but are often abandoned because of their complexity.
How true that is!

So my search took me through the links at the bottom of the page, until I hit upon Unitils: http://unitils.org/cookbook.html.  Instead of writing a complex fixture to encapsulate the data safely you write XML that describes the data needed for a given test.  This is associated with the class or method using a naming strategy, although this can be overridden by specifying files.  This could be handy if one dataset fits several test classes.  This is already easier than writing actual insert statements and can be achieved easily with the database schema browser and a text editor.  I am not interested in the mocking or database setup described there, whilst useful I had solved most of those issues with spring.  In fact unitils uses spring under the hood, so is probably using the same facilities I do in my work.  Unitils provides some powerful aid with the assertions in the test too, take a look at this!

ReflectionAssert

The reflection assert class provides a toolkit that addresses the kind of problems you often run into when making assertions against the data a DAO returns.  For instance lets say you have a model object with a primary key value.  This field is often hidden from you, and may not be used in the equals method.  In fact the equals methods on model objects are not always implemented or have some business specific implementation, so you can’t rely on them in the tests.  My solution was to use my own holder objects for data, and then to write my own validation routines against the model object.  Time consuming!

Take a look at these examples taken directly from the tutorial, (thanks guys!)

import static org.unitils.reflectionassert.ReflectionAssert.*;

// Exact field-by-field comparison
assertReflectionEquals(
  new Person("John", "Doe", new Address("New street", 5, "Brussels")),
  new Person("John", "Doe", new Address("New street", 5, "Brussels"));

// Ignore Null / 0 values in the expected object
assertReflectionEquals(
  new Person("John", null, new Address("New street", 0, null)),
  new Person("John", "Doe", new Address("New street", 5, "Brussels"),
ReflectionComparatorMode.IGNORE_DEFAULTS); 

// Ignore collection order
assertReflectionEquals(
Arrays.asList(
  new Person("John"), new Person("Jane")),
  new Person[] {new Person("Jane"), new Person("John")},
ReflectionComparatorMode.LENIENT_ORDER);

// Ignore null/0 values + collection order
assertLenientEquals(
  Arrays.asList(
  new Person("John"), null),
  new Person[] {new Person("Jane", "Doe"), new Person("John", "Doe")});

// Check only the firstName property
assertPropertyLenientEquals("firstName", Arrays.asList("John", "Jane"),
  new Person[] {new Person("Jane", "Doe"), new Person("John", "Doe")});

Comments on the assertion example

• Note the way its possible to ignore null and defaults like ’0′ and certain fields.  This should mean I can use constructors on my model and not have to worry about keys.  These are tested because you get data back in the child tables anyway.
• Note the system for ignoring order.  I use google multiset but this is even simpler than that.

General Problems that might still arise

I am not sure if my model is always going to be so accommodating.  I hope that visibility of appropriate constructors will allow the assertions I want to make via reflection.  I guess there is little impact in adding more for testing, but my design meant I did not have to worry about it because my assertions are made against an object provided by the fixture.  In fact the design of this object was to facilitate creation without complex constructors.  A constraint the model does not have to worry about.  i.e Only the DAO needs to create a model object  This also had the advantage of reducing the failure to one point, the DAO.  In the system above, you type data into the XML and into the test, so its possible to miss the match and the test will fail.

It will be interesting to see if its possible to work with nested objects and complex graphs. JPA or currently Hibernate is knitting things together so it may not be possible to create the objects required.  Its going to take a bit longer to finish this off, so I will explore further and post up my finished result later on.

If I had a request it would be for this framework to load a model object off the xml defining the data, and have an assertions like this:

public void validateModelLoadedFromTestDataAgainstReturnedModel(T y)

This would close the loop would it not?

Links

http://www.dallaway.com/acad/dbunit.html

http://www.theserverside.com/tt/articles/article.tss?l=UnitTesting

http://unitils.org/tutorial.html#Testing_with_JPA