Rules

Last Updated On

The rules testmethod allows you to check a dataset for different criterias (rules). The rules are defined in an expression-language based on C#. This gives maximum flexibility.

Prerequisites

  • Exactly one probe must be defined to run the rules testmethod.

Parameters

  • none

Results

SuccessfulAll validation rules were successful. That means that all records of the single probe fulfilled all rules completely or within the tolerance defined.
FailedAt least one rule failed.

Rule Configuration Dialog

The following dialog is used to define or edit a rule.

Name, Description, Active

Each rule has a unique name and an optional description. It can be activated or deactivated using the “Active”-switch.

Checks probe

Select the probe of the test case that gets checked by this rule.

Max. Rule Breaches

Sometimes, you need to define a tolerance value to allow a specific amount of rule breaches. This can be done using the Max. Rule Breaches settings either using a percentage of the total amount or records that get tested by this rule, or by setting an absolute number of records that are allowed to breach the rule.

Rules Expression

The Rules-Expression is a C#-script that gets executed for every record of the dataset (=probe) that gets validated by the rule. The rules-expression must return a boolean value which represents the status of the current validation. True means that the record fulfils the rule. False means, it doesn’t fulfil the rule.

There are two ways to write a rule-expression. Either as a simple single line expression or as a script with multiple lines.

Single line expression

A single line expression starts with an equal-character (=) followed by a logical expression. The expression is written in C#.

=Data("BirthDate").DateTime.Year >= 1970

Script expression

A script expression doesn’t start with a special character. There can be any line of code. But the last line must be a return command which returns a boolean-value.

Please note, that in contrast to the single line expression, the syntax expression requires to end each line witht a semicolon. This comes from the syntax-definition of C#.

// Caclulate the employees age using the birthdate.
var age = DateTime.Today.Year - Data("BirthDate").DateTime.Year;

// Convert vacation-hours to vacation-days.
var actualVacationDays = (double)Data("VacationHours").Decimal / 8.5;

// Set the target vacation-days count depending on the employees age.
var availableVacationDays = 0;
if (age <= 25) {
  availableVacationDays = 25;
}
else {
  availableVacationDays = 20;
}

// Compare the actual vacation days against the target.
return actualVacationDays == availableVacationDays;

Imports

Availability: since Release 2.8.0

BiG EVAL allows to use the full .NET framework with all its libraries within your custom scripts. Accessing specific classes may require defining imports also known as using-clauses in C#. Without these imports you are required to write the full qualified class-name everytime you are using a class. The following example shows how to import a specific namespace into your script.

using System.Text.RegularExpressions;

Pre Execute

Availability: since Release 2.8.0

BiG EVAL compiles each rules expression before running it for every record of a probe. This makes the evaluation of the rules expressions very fast. Despite of that, there may be situations where that’s not enough.

Utilizing regular expressions for example is slow as the regular expression itself get’s interpreted for every record. It would be much quicker to pre-compile the regular expression once in upfront before validating every record.

Another example is a lookup into a database-table that needs to be done for every record. It would be much faster to query the full table into memory once and using that in-memory representation to do the lookup.

The pre-execute-script allows exactly this. You can put all preparation commands into the pre-execute section of the rule. When running the test case or more specific, the rule, the pre-execute-script gets run first in upfront of validating every record. All variables defined in the pre-execute-script are then available in the rules-expression. So, you may compile a regular expression and store the compiled representation in a variable as the following example shows.

Pre-Execute (executed once in upfront):

Note that the variables emailFieldName and regex get defined in this script.

// The name of the column in your probe, that contains the email-address.
var emailFieldName = "EmailAddress";

// The following regular-expression checks the format of an email-address.
// The regular-expression gets compiled to perform much better when used many
// times by the rules-expression applied to every row of the probe.
var regex = new Regex(
    @"^([\w\.\-]+)@([\w\-]+)((\.(\w){2,})+)$", 
    RegexOptions.Compiled);

Rules Expression (executed for every record):

Note that the variables emailFieldName and regex are used in this script. They come from the pre-execute script where they were prepared.

// Extract the email-address from the current row.
var emailAddress = Data(emailFieldName).String;

// Check its format using the compiled regular expression.
return regex.IsMatch(emailAddress);

Table of Contents