Contents


Write unit tests for IBM Cúram Social Program Management

Using CuramServerTest with JUnit

Comments

Social program management organizations (such as public sector human services, workforce services, and social security agencies) are facing increased demand and higher service expectations from their clients, while simultaneously feeling pressure to contain costs and optimize outcomes. The Cúram Social Program Management Platform provides pre-built social program specific components, business processes, toolsets, interfaces, and configuration capabilities, that enable the delivery of solutions to support the increase in demand and service effectiveness.

The platform allows additional components to be developed to support specific project requirements using a set of extension mechanisms. As unit testing is an important part of quality software development, it is valuable to be able to write unit tests for any extensions developed on a given project.

Writing unit tests for Cúram Social Program Management application business processing

When extending the Cúram Social Program Management application, the starting point is the platform-independent application model. Cúram Social Program Management applications follow a service-oriented architecture, and services to be provided by the application are defined as UML interfaces in the model. All interfaces in the model are referred to as "business objects". Business object implementations are coded as plain Java™ objects (POJOs).

These Java objects are suitable for unit testing using a unit testing framework like JUnit (http://www.junit.org). However, many common setup and teardown activities (managing database transactions, and more) are needed for all tests. Additionally, several common tasks (such as calculations around the current date) are useful for many tests. To support this, a sub-class of the JUnit TestCase has been created called CuramServerTest. Writing unit test classes that inherit from this class is a significantly simpler undertaking than using the JUnit TestCase and managing the common functionality directly.

Writing a simple unit test using CuramServerTest

In general, after the unit test inherits from CuramServerTest the implementation can follow the normal structure for a JUnit test, calling elements of the SPM application without any additional consideration. To show how this might work, let’s take an example to write JUnit test for a new process.

Listing 1. Sample class declaration
public class MyBusinessProcess extends curam.test.framework.CuramServerTest {

  // …

}

Constructor

Every unit test requires its own constructor be declared. In general, it's safe to defer to the CuramServerTest constructor. However, additional steps can be included, for example, to construct any business object instances that are needed by a number of the test implementations.

Listing 2. Sample class declaration
public MyUnitTest(String arg0) throws AppException, InformationalException {

  super(arg0);
  myBusinessProcessObj = curam.custom.fact.MyBusinessProcessFactory.newInstance();

}

Default flow

Most unit tests require at least one test to cover the default flow (what might be called the happy path) where the most commonly executed successful path(s) through the logic are tested. When using the JUnit framework, all test methods require a name starting with test and no return parameter declared.

Listing 3. Sample default flow
public void testDefaultFlow() throws AppException, InformationalException {

  // populate details
  myBusinessProcessDetails.someField = “some value”;
  myBusinessProcessDetails.someOtherField = “some value”;
  myBusinessProcessDetails.someNumericField = 0;
  myBusinessProcessDetails.someDateField = getToday();

  // create the record
  myBusinessProcessObj.create(myBusinessProcessDetails);

}

Testing for an exception

Another common pattern in unit tests is to set up an expected “error” condition and check that the expected message is returned.

Listing 4. Sample test for an exception
public void testValidationSomeFieldIsMandatory() throws AppException, 
  InformationalException {

  // populate details
  myBusinessProcessDetails.someField = “”;
  myBusinessProcessDetails.someOtherField = “some value”;
  myBusinessProcessDetails.someNumericField = 0;
  myBusinessProcessDetails.someDateField = getToday();

  // attempt create the record
  try {

    myBusinessProcessObj.create(myBusinessProcessDetails);

  } catch (curam.util.exception.AppException e) {
    
    // check for the expected exception
    assertEquals(curam.message.MYBUSINESSPROCESS.ERR_SOME_FIELD_MANDATORY, 
      e.getCatEntry());
    return;

  }

  // if the create succeeded, the test should fail
  fail("Expected exception: " + 
    curam.message.MYBUSINESSPROCESS.ERR_SOME_FIELD_MANDATORY.toString());

}

Writing your own setup and teardown processing

By overriding the setUpCuramServerTest and tearDownCuramServerTest methods of CuramServerTest you can add additional steps that are executed before (setUpCuramServerTest) or after (tearDownCuramServerTest) every test method. These are used in place of the JUnit setUp and tearDown methods (which have final implementations provided by CuramServerTest), as this ensures that any custom processing will be carried out while not interfering with the database transaction management provided by CuramServerTest.

Listing 5. Sample setup and teardown
public void setUpCuramServerTest() throws AppException, InformationalException {

  // …

}

public void tearDownCuramServerTest() throws AppException, InformationalException {

  // …

}

Database transaction management

Database transaction management is implemented by CuramServerTest. The default configuration is to have a single database transaction that runs for each test and is then rolled back. However, by overriding the shouldCommit method and setting it to return true, you can ensure that the database transaction will be committed after each test in a given test class. It’s important to ensure that when using this configuration no assumptions are made in your tests about the order in which tests are run (for example, by assuming that a fixed number of records will exist in particular table).

Listing 6. Using shouldCommit to commit database transactions
protected boolean shouldCommit() {

  return true;

}

Using CuramServerTest in your project

An implementation of the CuramServerTest class is included in this article. (See Download.) The class has been tested with IBM Cúram Social Program Management 6.0.3. Placing this class in any compiled location, where the folders corresponding to the package structure exist, should be sufficient for you to use it in your project. For example: EJBServer\components\custom\source\curam\test\framework. You will also need to download JUnit and place the junit.jar on the classpath (for example in EJBServer\components\custom\lib). The class has been tested with JUnit Versions 3.8 and 4.8. Other versions may work, but have not been tested and cannot be guaranteed to work correctly.

Conclusion

This article explained the best approach for writing unit tests when developing with IBM Cúram Social Program Management software. We learned how the CuramServerTest class can be used to write unit tests in a straightforward manner. We also discussed some of the features of this class that support more complex use cases. Using this approach it should be possible to rigorously test extensions developed on a given project, and ensure that these extensions operate reliably.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Middleware, Big data and analytics, Information Management
ArticleID=823238
ArticleTitle=Write unit tests for IBM Cúram Social Program Management
publish-date=07172012