Create test scripts from existing data

Using the batch processor it is possible to create test scripts. The batch processor can be configured to read from a database connection, or a directory of CSV files, so that it can generate a large number of test cases based on real-world data. The steps to create test scripts from existing data are:

Ensure data is in appropriate format for the batch processor
Run the batch processor to generate the test script
Add the test script file to OPM

Ensure data is in appropriate format for the batch processor

Format CSV files

Data can be read from a directory of files containing data formatted as comma-separated values (CSV). The files containing the data to be read must end with the .csv extension.

The batch processor supports a configuration-free option for CSV files as long as they follow the conventions below:

the CSV files need to be using headers (ie the first row of the CSV contains column names)
the name of a document needs to correspond to the public name of an entity (unless it is representing a many-to-many relationship)
column names are either:
- '#' for the primary key column (values must be an integer)
- the public name of an attribute
- the public name of an attribute enclosed in parenthesis - this represents an output attribute
- the public name of the 'to-one' side of a relationship - the column value is the primary key of the target entity instance
- the public name of the parent entity if the entity exists in a containment relationship

A special case is where a CSV file represents a many-to-many relationship. In that case the name of the document needs to correspond to the public name of one of the directions of the relationship. The CSV document is then required to have two columns with the first column having foreign key references to source entity instances and the second column with foreign key references to target entity instances (source and target are from the perspective of the side of the relationship used for the name of the document).

The expected format for attribute values is:

Value Type	Format Description	Blank Value
Number	Numeric values must adhere to the following conditions: The '.' character is the decimal separator Thousands separators are not supported Currency symbols are not supported For scientific notation, the '+' is not supported in the exponent	Blank values are considered UNCERTAIN
String	String values will be read as-is	Blank string values are considered to be a blank value
Boolean	Boolean values must adhere to the following conditions: String values are case insensitive, so "YES" is the same as "yes" and "Yes" Leading zeros are not truncated from numeric values "True", "Yes" and 1 will be parsed as TRUE "False", "No" and 0 will be parsed as FALSE	Blank values are considered UNCERTAIN
Date	Date values must adhere to the format "yyyy-MM-dd" where: yyyy is the four-digit year MM is the two-digit month, including leading zero for values below 10 dd is the two-digit day, including leading zero for values below 10	Blank values are considered UNCERTAIN
Datetime	Datetime values must adhere to the format "yyyy-MM-dd HH:mm:ss" where: yyyy is the four-digit year MM is the two-digit month, including leading zero for values below 10 dd is the two-digit day, including leading zero for values below 10 HH is the two-digit 24-hour hour value, including leading zero for values below 10 mm is the two-digit minute value, including leading zero for values below 10 ss is the two-digit seconds value, including leading zero for values below 10	Blank values are considered UNCERTAIN
Time	Time values must adhere to the format "HH:mm:ss" where: HH is the two-digit 24-hour hour value, including leading zero for values below 10 mm is the two-digit minute value, including leading zero for values below 10 ss is the two-digit seconds value, including leading zero for values below 10	Blank values are considered UNCERTAIN

If there is only a single CSV file in the folder, or one of the CSV files is "global.csv" then it is presumed to be the 'base' table, otherwise the base table needs to be specified. For example, a folder may contain "parent.csv" and "child.csv" - without specifying which is the base table, the batch processor won't know whether it should be processing cases for parents or children. Note that once a base table is established, other tables will be brought in as required by containment or reference relationships.

Convert Excel data to CSV format

You can use Excel to perform batch generation of test scripts for Oracle Policy Modeling. You just need to convert the data into CSV format first. To do this:

Set up the data in Excel.

For example, to set up 101 cases where the "income" attribute is stepped from 0 to 100,000.

On a blank worksheet you would enter the following and then use 'fill down' to replicate the last row down to row 1002.

#	income
1	0
=a2+1	=b2+1000

Make sure that the data is formatted according to the conventions defined earlier.
Create a directory in Windows Explorer and save the file in CSV format as "global.csv".

Run the batch processor to generate the test script

The batch processor is invoked from the command line. To generate a test script you will need to specify at least the following parameters:

the rulebase location (--rulebase <rulebase path>)
the data source (--csv <folder> or --database <db-connection-string>)
the test script location (--exporttsc <path>)

Note that the data source can be specified in the XML configuration file to be used by the batch processor instead of as a command line parameter.

For more details, see the Batch Processor section of the Oracle Policy Automation Developer's Guide.

Add the test script file to OPM

In the Oracle Policy Modeling project, add the generated tsc file from the previous step (File | Add |Add Existing File...). You can then use the regression tester in OPM to customize the test script. See Define, modify or remove test scripts for more information.