◷ Reading Time: 7 minutes
FlexRule authoring platform -FlexRule Designer- enables users to define and model test cases that can be used for testing all aspects of your business logic.
Building the test cases does not require programming skills, and defining, modeling, and running test cases are all integrated into FlexRule Designer.
Introduction
Test documents allow you to build a test scenario for your business logic (e.g., decisions, rules, etc.). In writing tests there are four levels:
- TestCase: This is a testing scenario for a particular logic (e.g., a decision table)
- Sections: Each scenario can be broken down into different hierarchical categories, called sections.
- Tests: Each section may contain one or more tests.
- Asserts: Each test may check one or more expectations (assertions).

Create a New Document
Open a FlexRule project, go to FlexRule–>New menu, and select the following section from the new document screen:

Once the test document is added, you can see an empty tree document with the main node of TestCase and toolbox to create and model your test scenario.
Building Test Model
To learn more about how to create a tree, check the Building tree instruction.
TestCase
A TestCase has the following properties:
- Name: A name of the test case or scenario
- Logic File: reference to the rule/logic file for this specific scenario
On entering a Logic File value, you can choose to select the project explorer as shown below:

Section
Sections are a way of grouping tests logically so that these can be run on Explorer and also together. You can specify a Name for your section. Please note sections can be hierarchical – very similar to your operating system directories (folders).
Test
Under each section, you can have multiple tests. A test has the following properties:
- Name: Specifies the name of the test – human-readable and a descriptive name for a test.
- Data Feed Provider: Specifies the provider that pushes some data to the test to run the business logic.
- Input: The name of the input from the data provider screen.
- Logic: Name of the logic to test (e.g., Validation may contain multiple logic, so you can target a specific logic in the test).
Target: Sometimes in testing validation logic you may want to send an object as the defaultObject. You can specify a parameter name to be used as the default object.
Data Feed Provider and Input
Tests can run by providing data to the logic file (when required). This uses the same screen that you see for debugging.
Please note in the Data Feed Provider screen, the valid options for Tester are JSON Composer, Data composer, and Procedural Rule. For the Data composer data provider, Logic is not required.
JSON Composer
You can also use the JSON Composer option to feed data for testing.

For example, the given screen uses the following JSON file.
1000.js.json
{
"person":
{
"Income":1000,
"Tax Amount":0.0
}
}
Assertion
You may have one or more assertions under each test that will assert an expectation of running a test for a scope.
Here are the following properties available for an assert:
- Expression: Specifies the expectation of an assertion.
- Scope: An assert can be validated for different scopes:
- Parameter: Allows you to assert an expectation for the parameters of a logic
- Return: Allows asserting expectation for the return value of a logic
- Notification: Allows asserting expectation against Notification as the result of logic execution.
- Parameter Name: Specifies the parameter of the logic to be used as the $actual value used in the expression.
Variable Reference
In writing expressions for assert, you need to access the values for parameter and return a value and notification. To do that you can use:
- $actual: for the return value and parameter assertion
- $notification: to access the notification object of the execution
When using $actual, the object is in the type you specified in your parameters, but when $notification is used it has the following definition:
class NotificationUtility
{
public Notice Get(int index);
public int Count;
public Notice Get(string message);
public Notice Get(string message, NoticeType type);
public int CountType(NoticeType type);
}
class Notice
{
public string Message { get; set; }
public NoticeType Type { get; set; }
}
Parameter Name
Asserting an expectation on a parameter can be achieved by selecting the scope as Parameter. Then you need to specify the name of the parameter which will be accessed by $actual on the assertion expression.
To select the parameter name, you can simply use the parameter combo box by selecting the … button.

Example Expression
Notification Assert
For example:
$notification.Count == 1

With the scope set to Notification, this passes when one and only one notice is available after the logic has run.
Parameter Assert for Objects
or for an example expression
$actual.Point == 1

With the Scope set to Parameter and Parameter Name set to the logic parameter, this will pass only when Point has the value equal to 1 after the logic has run.
Please note we have used AssertTrue as the type of assertion.
Parameter Assert for String
or for an example expression
$actual=='Hello'
With the Scope set to Parameter and Parameter Name set to the logic Parameter (assuming the parameter’s result is a string value), this will check if the parameter result is the value of Hello

Assertion Types
There are different types of assertions that check for the expectation (Expression property of assert):
- AssertTrue: Passes when the expression returns true.
- AssertFalse: Passes when the expression returns false.
- AssertNull: Passes when the expression returns null.
- AssertNotNull: Passes when the expression returns any object but a null value.
Validate
Make sure you validate your test model before running it. The validation will find possible errors with your test structures and properties.

Video Tutorial
Download Project
Use the attachment at the end of the page to download the project used in both the page and the video tutorial.