Unit Testing

Dynamic Logic modules may contain complex logic. It is therefore essential for customers to test they still behave properly. Their functioning can be impacted by new application versions, new configuration data or new seed data.

Testing of dynamic logic can be divided into:

1. unit testing: the various use cases the unit should be able to handle are validated.

2. integration and/or system testing: the unit is tested as part of the complete flow of the system and application

Integration testing is more expensive from a time and processing perspective. It also needs a completely configured system to be able to handle the complete flow. The feedback cycle is generally slow. As complete flows are executed, the tests changes the state of the application. Typically a restore action of some sort is needed before one can run the tests again.

Unit testing tests the unit in isolation. The feedback cycle is short. Correctly written unit tests are independent of each other. They are also idempotent: one can run them over-and-over again without the new for any restore action.

This page describes how unit tests are supported by Oracle Health Insurance applications.

Unit Test

Unit tests are coded as Groovy logic of signature "Test Unit".

This page is not a unit testing guide. It is in short advisable to write short unit test that test a single use case for a single unit.

The Test Dynamic Logic Integration Point executes a single dynamic logic unit test.

Oracle Health Insurance applications have no features to test a set of unit tests at one go. This needs to be scripted outside the Oracle Health Insurance application.

import com.oracle.healthinsurance.integration.gateway.exchange.component.datafile.*
def fileReader = new DataFileReader()

A typical unit test looks like this:

//1. Construct input objects
def input1 = ...;
def input2 = ...;

//2.
def result = test( "<Dynamic Logic Code>", [
    "<key1>" : input1,
    "<key2>" : input2
])

//3.
if( result.<some check>>) {
    log( "<Some error message>" )
    return false;
} else {
    log( "<Some success message>" )
    return true;
}

1. Input objects are created. They may be fully constructed in the unit test, or they may be retrieved from the database as pre-defined test data.

2. The unit-under-test (UUT) is called. The pre-defined "test" function is used.

3. Verification of the outcome. When as expected, true should be returned; false otherwise.

Security context

Security contexts protect which actions are possible in dynamic logic. In the test unit itself, there are no restrictions: it should be possible to define any object in any given state as input for step 2. The "test" function uses the same security context as is used by the Oracle Health Insurance application in the actual invocation. So the same restrictions apply.

Although any object can be changed in a test unit, this does not impact the idempotency of the test. The whole unit test uses a "rollback-only" transaction, so it is not possible to store any changes made by the unit test in the database.