How to write TestCase for OpenJPA?

OpenJPA Unit Tests are JUnit Tests. Base JUnit TestCase (org.junit.TestCase) has been extended to facilitate common initialization steps or configuration settings required for unit testing OpenJPA. As a test developer, you should inherit your test class from one of the extended TestCases. This also helps the test you write to be integrated with OpenJPA test corpus of approximately 2000 test cases in 400 classes.
The inheritance hierarchy is:

junit.framework.TestCase
    org.apache.openjpa.persistence.test.PersistenceTestCase
        org.apache.openjpa.persistence.test.SingleEMFTestCase
            org.apache.openjpa.persistence.test.SQLListenerTestCase

SingleEMFTestCase is a good candidate for inheritance unless your test needs to analyze or count number of SQL statements in which case SQLListenerTestCase should be your choice.

Setting up the test

JUnit tests are setup in their setUp method. OpenJPA TestCases augment the setUp() method to accept a list of arguments. In this list, you should specify

• the domain classes used by your test
• the configuration properties that are critical to your test
• CLEAR_TABLES or DROP_TABLES : these are constants declared in the superclass which clears the rows or drops the tables altogether.

The following example shows how to declare setUp() method in your test class

public void setUp() throws Exception {
    setUp(CLEAR_TABLES,                      // clears rows from PERSON and ADDRESS table
          Person.class, Address.class,       // registers Person and Address as persistence-capable entity
          "openjpa.Multithreaded", "true");  // sets configuration property as name-value pair
}

Configuration of Persistence Unit

Notice that some configuration parameters can be set in the setUp() method of test program itself. This is recommended for properties that are important for your test. The non-critical parameters such as database connection properties (unless your test is about some specific aspect of a particular database) are better be specified in META-INF/persistence.xml.

The name of the persistence unit is, by default, "test". But your test should overwrite the name with a more specific unit name. For example,

protected String getPersistenceUnitName() {
    return "test-eager-fetch";
}

Cleaning Up

Specifying CLEAR_TABLES or DROP_TABLES in the list of setUp() parameters helps to minimize impact of one test on another. Remember that the test you are writing will run with 2000 other tests in a batch.

JUnit TestCases invoke tearDown() method on termination. SingleEMFTestCase ensures that tearDown() method deletes all rows for the classes involved in your test. While clear-your-own-mess helps in most situations, you may want the database records to remain for analysis especially when tests are failing. In that case you may consider suppressing the superclass behavior of tearDown() by simply nullifying the method as

public void tearDown() throws Exception {
     // avoids super class to delete all records
}

Naming Convention

Name your test class and test methods with following guideline in mind

• Test case class names start with "Test" e.g. TestEagerFetch
• Test method names start with "test" e.g. testUpdateHonoursForeignKeyConstraints()
• Be generously descriptive with camel case e.g. TestEagerFetch or testFetchGroupLocking()
• avoid the obvious e.g. TestSelect or testQuery()

Domain classes

• Domain classes should avoid common names such as Person or Address.
• Prefer annotation over XML Descriptors for O-R Mapping because that helps to colocate relevant information. Unless, of course, the test is specific about variations in behavior across annotation and XML Descriptors.