Testing

For a complex product created in a development environment, you should create unit tests for individual parts of your product's decision details rules, using CER's support for rules testing.

You might consider creating end-to-end unit tests that test full scenarios involving the creation and activation of evidence, and the creation and activation of product delivery cases, to test that the overall decision details results are calculated as expected.

You might also perform manual testing of the online system to check that your overall decision details scenarios are handled as expected. This step is particularly important for decision details, as the implementation of decision details involves custom screens (unlike the display of eligibility/entitlement and key decision factor results, which use screens included with the Engine).

It is particularly important to ensure that the XPath-like expressions in your Dynamic UIM screens matches the structure of the XML data produced by the Engine when it creates a determination; the structure of the XML data is in turn mandated by the annotations on your case rule object for the product period/display category.

Tip: In a development environment, it can be useful to set breakpoints on the CaseDetermination facade method(s) called from your Dynamic UIM pages, so that you can inspect the XML returned. In a situation where a screen value is failing to display as intended, it can be useful to see if:

the value is present in the returned XML, in which case the error most likely lies with your XPath-like expression in the Dynamic UIM; or
The value is not present in the returned XML, in which case the error most likely lies with the annotations in your rule classes for decision details.

Note that it is possible for the XML returned from the server to contain data which is not used on any decision details screen. Under rare circumstances, it is possible for a case worker to view a determination, shown as a number of coverage periods, with the decision details for those coverage periods seeming (to the case worker) to appear as identical. In this situation, it is possible that the Engine is splitting the determination into coverage periods based on some data in the XML which is not shown to the user. You should take care to ensure that there is no such extraneous data in your XML - i.e. that all Display attributes do in fact appear on one or more decision detail screens or subscreens.

The Engine may encounter runtime problems when calculating decision details for a particular display category, due to calculation errors in CER attribute values.

If there is a runtime error in the calculation of a CER attribute value for a display category, such as a reference not found (analogous to a NullPointerException in Java), or a division by zero, or any other calculation problem, then the Engine will throw an exception. The application logs will contain details of this exception including its stack trace. For CER calculation errors, the stack trace can include important information regarding the location within a CER rule set where the error occurred. To fix this, you will need to debug and retest your rules.