Tips on writing TestCase for OpenJPA
You are welcome to contribute new test cases. Following are few suggestions and guidelines on how to contribute new test case to OpenJPA repository of 2000 test cases spread across 400 classes.
How to write TestCase for OpenJPA?
...
| Tip |
|---|
| title | Inherit from OpenJPA TestCases |
|---|
|
Unit Tests are JUnit Tests. The base JUnit |
...
| Code Block |
|---|
test case implementation org.junit.TestCase has been extended to facilitate common initialization steps or configuration settings |
...
...
...
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 |
| Code Block |
|---|
As a test developer, you should inherit your test class from one of the extended TestCases. In general, SingleEMFTestCase is a good candidate to inherit from. If your test needs to analyze or count number of SQL statements, |
...
SQLListenerTestCase
should be your choice. |
Setting up the test
A JUnit test is set up in
method. OpenJPA TestCases augment the
| Tip |
|---|
| title | Use correct name and package for test case and entity classes |
|---|
|
- Test case should be in a separate sub-package of
org.apache.openjpa.persistence. or org.apache.openjpa.persistence.jdbc.
- Test case class names must start with "Test" e.g.
TestEagerFetch
- There are hundreds of testable entity classes. But if your test requires new entity classes, place them in the same package as that of the new Test cases.
|
| Tip |
|---|
| title | setUp() and tearDown() |
|---|
|
- OpenJPA TestCases augment the
setUp() method to accept a list of arguments. In this list, you should specify:
|
...
- entity classes used by your test
- the critical configuration properties
|
...
CLEAR_TABLES or DROP_TABLES : these are constants declared in the superclass which clears the existing rows or drops the tables altogether.
|
...
...
- method
| Code Block |
|---|
public void setUp() throws Exception {
super.setUp(CLEAR_TABLES, // clears records for domain classes
Candidate.class, Election.class, // registers Candidate and Election as persistence-capable entity
"openjpa.Multithreaded", "true", // sets configuration property as name-value pairs
"openjpa.Log", "SQL=TRACE");
}
|
|
...
| Code Block |
|---|
- Notice that some configuration parameters can be set in the
|
...
| Code Block |
|---|
- 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
|
...
.
...
- . The persistence name can be specified by overwriting the following method:
| Code Block |
|---|
protected String getPersistenceUnitName() {
return "test-eager-fetch";
}
|
|
Cleaning Up
Specifying
or
parameters helps to minimize impact of one test on another. Remember that the test you are writing will run with 2000 other tests.
A JUnit TestCase invokes
method on termination.
...
- method deletes all rows for the domain classes involved in your test.
|
...
| Code Block |
|---|
- 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
|
...
- by simply nullifying the method as
| Code Block |
|---|
public void tearDown() throws Exception {
// avoids super class to delete all records
}
|
|
Naming Convention
Name your test class and test methods with following suggestions:
- 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.
- Test method names start with "test" e.g.
| Code Block |
|---|
testUpdateHonoursForeignKeyConstraints() |
. - Be generously descriptive with camel case e.g. or
| Code Block |
|---|
testFetchGroupLocking() |
- avoid the obvious e.g. or
Domain classes
| Tip |
|---|
| title | Annotate O-R Mapping |
|---|
|
Prefer annotation over XML Descriptors for O-R Mapping because that helps to |
...
collocate relevant information. Unless, of course, the test is specific about variations in behavior across annotation and XML Descriptors. |
- Describe the purpose of the test on class comments
- If the test is related
| Tip |
|---|
| title | Use JUnit assert*() methods |
|---|
|
For verification, use many assertion methods provided by JUnit e.g. assertEquals() or assertTrue() rather than depending on printing trace with System.out.println(). If you want to trace generated SQL or other runtime information, use appropriate openjpa.Log property settings. |
| Tip |
|---|
|
Create a JIRA issue. Refer to the JIRA issue in the comments section of the new test case. |
| Tip |
|---|
|
Remember to include ASF License header in the comment section of all the new source or resource files. |
| Tip |
|---|
| title | Attach the test to JIRA Issue |
|---|
|
Package all the *.java files related to your test case in a JAR file and attach it to JIRA issue you have created.
You must check in the radio button Grant license to ASF for inclusion in ASF works that appears near the bottom of Attach File JIRA page. |
...
