Skip Headers
Oracle® Communications Design Studio Modeling Activation
Release 7.2.4
Go to Design Studio Help Home
Go to Table of Contents
Go to Feedback page

Go to previous page
Go to next page
Mobi · ePub

Understanding Unit Test Property Files

You use a set of property files to set up a unit test (both are property file and follow the Java property file format):

Testdata file

The testdata format for naming the input parameters is similar to that within a work order. However, you must populate the test data with atomic action labels (and not service action labels). Run the unit test as if the parameters have been previously defaulted.

Apply the defaults that are normally set by the SARM (based on what is configured in the atomic action) as if they had been applied in the test data (the processor runs after those defaults have been set). The unit test data should be based on data that has already been defaulted and based on names relating to the atomic action label (and not the service action label).

When you fill in the test data for compounds or incoming repeating elements, use square brackets to indicate the index for a compound as in the following example.

# Example Action Processor input property file
NETID=ERIC-SDP_3-6-2-HOST 
MSISDN=0701234567 
FAF_LIST[1].FAF_N=0701237777 
FAF_LIST[1].TSC=O 
FAF_LIST[1].RCO=1 
FAF_LIST[1].K=400 
FAF_LIST[2].FAF_N=07052 
FAF_LIST[2].TSC=4 
FAF_LIST[2].K=100 
FAF_LIST[3].FAF_N=071 
FAF_LIST[3].K=500

Testinfo file

You can use this optional file to define the properties for which you are testing. You can also define what expected request the processor should create, the expected canned response returned to the processor, the expected exit type and whether it should be tested.

Note:

If you do not define a testinfo file, then by default the test case only tests whether the exit type is succeed (that is, to confirm that the test data has gone through).
# Example Action Processor test info property file
request.check=true 
request.value=Test Message
response.value=Test Response
# Exit Type values: 
# SUCCEED 
# FAIL
# RETRY 
# MAINTENANCE 
# SOFT_FAIL 
# DELAYED_FAIL 
# STOP
exittype.check=true 
exittype.value=SUCCEED

If you wish to have multiple request and response values in your test, you can specify multiple values in the testinfo file. Add a dot separated numeric suffix to the value (starting at 1).

If your request or response has multiple lines or special character, follow the standard Java property guidelines.

# Example Action Processor test info property file
request.check=true 
request.value.1=Test Message 1
request.value.2=Test Message 2
response.value.1=Test Response 1
response.value.2=Test Response 2
# Exit Type values: 
# SUCCEED 
# FAIL 
# RETRY
# MAINTENANCE 
# SOFT_FAIL 
# DELAYED_FAIL 
# STOP
exittype.check=true 
exittype.value=SUCCEED

Related Topics

Understanding Unit Testing

Working with the Action Processor

Modeling Entities