Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

OpenJPA Unit Tests are JUnit Tests. Base The base JUnit TestCase (

Code Block
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:

Code Block
junit.framework.TestCase
   +-- org.apache.openjpa.persistence.test.PersistenceTestCase
       +-- org.apache.openjpa.persistence.test.SingleEMFTestCase
          +--  org.apache.openjpa.persistence.test.SQLListenerTestCase
Code Block
In general, SingleEMFTestCase

is a good candidate for inheritance unless to inherit from. If your test needs to analyze or count number of SQL statements in which case SQLListenerTestCase ,

Code Block
SQLListenerTestCase

should be your choice.

Setting up the test

A JUnit test is set up in

Code Block
setUp()

JUnit tests are setup in their setUp method. OpenJPA TestCases augment the

Code Block
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 shows an example

Code Block
setUp()

method in your test class

Code Block
public void setUp() throws Exception {
    super.setUp(CLEAR_TABLES,                      // clears rowsrecords fromfor PERSON and ADDRESS tabledomain classes
          PersonCandidate.class, AddressElection.class,       // registers PersonCandidate and AddressElection as persistence-capable entity
          "openjpa.Multithreaded", "true");,   // sets configuration property as name-value pair pairs
          "openjpa.Log", "SQL=TRACE");       
}

Configuration of Persistence Unit

Notice that some configuration parameters can be set in the

Code Block
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

Code Block
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,

Your test may specify the persistent unit via the following:

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

Cleaning Up

Specifying

Code Block
CLEAR_TABLES

or

Code Block
DROP_TABLES

in the list of

Code Block
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

A JUnit TestCase invokes

Code Block
tearDown()

method on termination.

Code Block
SingleEMFTestCase

ensures that

Code Block
tearDown()

method deletes all rows for the domain 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

Code Block
tearDown()

by simply nullifying the method as

...

Name your test class and test methods with following guideline in mindsuggestions:

  • Test case must be in a separate sub-package of
    Code Block
    org.apache.openjpa.persistence.*"
    or
    Code Block
    org.apache.openjpa.persistence.jdbc.*"
  • Keep the domain classes and Test cases in the same package
  • Test case class names must start with "Test" e.g.
    Code Block
    TestEagerFetch
  • Test method names start with "test" e.g.
    Code Block
    testUpdateHonoursForeignKeyConstraints()
    .
  • Be generously descriptive with camel case e.g.
    Code Block
    TestEagerFetch
    or
    Code Block
    testFetchGroupLocking()
  • avoid the obvious e.g.
    Code Block
    TestSelect
    or
    Code Block
    testQuery()

...

Domain classes

...

  • 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.

Comments

  • Describe the purpose of the test on class comments
  • If the test is related

ASF License