Designer:Test builder

From FlexRule Wiki
Jump to: navigation, search

FlexRule Designer > Testing > Test document


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:

  1. TestCase: This is a testing scenario for a particular logic (e.g., a decision table)
  2. Sections: Each scenario can be broken down into different hierarchical categories, called sections.
  3. Tests: Each section may contain one or more tests.
  4. Asserts: And each test may check one or more expectations (assertions).

FlexRule Designer Testser.png

Create New Document

Open a rule project, go to Rule->New menu and select the following section from the new document screen:

Tester-New TestCase.png

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, please check Building tree instruction.

Try to build a model like the TestCase shown below:

Tester-SampleTestCase.png

TestCase

A TestCase has the following properties:

  1. Name: A name of the test case or scenario
  2. Logic File: reference to the rule/logic file for this specific scenario

Please note, on entering a Logic File value, you can chose to select the project explorer as shown below:

Section

Sections is 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:

  1. Name: Specifies the name of the test - human readable and a descriptive name for a test.
  2. Data Feed Provider: Specifies the provider that pushes some data to the test to run the business logic.
  3. Input: The name of the input from the data provider screen.
  4. 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 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 (Simple_Debugging).

Please note in the Data Feed Provider screen, the valid options for Tester are Data composer and Procedural Rule. For Data composer data provider, the Logic is not required.

Assertion

You may have one or more assertions under each test which will assert an expectation of running a test for a scope.

Here are following properties available for an assert:

  1. Expression: Specifies the expectation of an assert.
  2. Scope: An assert can be validated for different scopes:
    1. Parameter: Allows you to assert an expectation for the parameters of a logic
    2. Return: Allows asserting expectation for the return value of a logic
    3. Notification: Allows asserting expectation against Notification as the result of logic execution.
  3. 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:

  1. $actual: for return value and parameter assertion
  2. $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.

Tester-assert-parameterName.png

Example Expression

Notification Assert

For example:

$notification.Count == 1

Tester-assert-notification.png

With 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

Tester-assert-parameter.png

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 the 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 value of Hello

Tester-assert-string-value.png

Assertion

There are different types of assertion which check for the expectation (Expression property of assert):

  1. AssertTrue: Passes when the expression returns true.
  2. AssertFalse: Passes when the expression returns false.
  3. AssertNull: Passes when the expression returns null.
  4. AssertNotNull: Passes when the expression returns any object but 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.

Tester-validate.png

What's Next?

  1. Building a test case
  2. Running a test case or part of it
  3. Testing rules expressions syntax