Pega unit validations

The Pega unit framework offers a variety of validations to help users comprehensively evaluate the output returned by a Pega unit test. Understanding each of these validations helps users utilize the correct validation required for a particular unit test. It is often necessary to use multiple validations in a single Pega unit test to make the test more effective.

Following is the list of validations offered by Pega unit framework along with their description. 

Property

This validation is the basic validation that is applicable for every supported rule type. The Property validation is added as a default by the Pega unit framework in every test case except for decision test cases. This validation can be deleted by users if not required. 

The following image shows an example of a property validation. In this assertion, the actual value of the property, .pyWorkIDPrefix, is compared with the expected value "ME-". When the actual value of the property is not equal to the expected value, the property validation fails.
 

For information about how to configure a property validation, see Configuring property assertions.

Result count

This validation can be configured by users to compare the number of items that are returned in a page list, page group, value list, or value group on the rule, with the result on the clipboard. 

For more information on how to configure the result count validation, see Configuring result count assertions.

Expected run time

This validation can be configured by users to validate the run time of a rule. The expected run time assertion is less than or equal to an amount of time, which users specify, in seconds.

A run time that is significantly longer than the expected run time can indicate an issue.

For example, if you use a report definition to obtain initial values for a data page from a database, there might be a connectivity issue between the application and the database. As a result, the rule takes longer to run.

By default, the system generates the expected run time validation after you create a Pega unit test case for a rule. The default value for the expected run time is the time that the rule takes to execute when users first run the test. The system compares the expected run time with the run time of the rule for all future tests.

You can change the default value and configure the expected run time validation for all rule types.

The following image is an example of an expected run time validation in which the run time of the rule is less than or equal to 0.05 seconds. The test is configured to fail when the validation fails. If this validation is not configured to fail the test case, the test case displays a warning but does not fail the test case. 

For more information about configuring an expected run-time validation, refer to Configuring expected run-time assertions.

Page

This validation can be configured by users to validate pages on the clipboard that are manipulated by a rule which is run as part of the unit test case. 

It is possible to configure page validations for embedded pages, data pages, data pages with parameters, and embedded pages within data pages that either have or do not have parameter step-level pages. 

The following image is an example of page validation. In this example, a data page D_AddressList is verified for existence on the clipboard. If this data page does not exist on the clipboard, the page validation fails. 

For more information about configuring page validation, refer to Configuring page assertions.

List

This validation can be configured by users on page lists that are returned by a rule to determine one of the following conditions: 

• Whether the expected result is present in the list of results that are returned by the rule. The comparator value for this type of validation is In ANY instance.
   
• To compare the expected result with all the results that are returned by a rule so that you do not have to create validations for each result in the list manually. The comparator value for this type of validation is In ALL instances.

  The following image is an example of a list validation. In this scenario, four different properties are compared with the expected values in any of the results returned by the list object. The list validation fails when none of the results match the configured values for all the expected property values. 

  

  For more information on how to configure a list validation, see Configuring list assertions.

Activity status

This validation can be configured by users to verify if an activity returns the correct status after it is run. This validation can also verify whether an activity has an error. If an error occurs, this validation can also determine if the status message of the activity is correct. 

The following image shows an example of the activity status validation. In this scenario, the status of the activity is equal to GOOD, and the Activity status message is equal to the No Errors message. This validation fails if either of the comparisons fail.

Decision result

This validation appears by default in the test case rule form while testing decision rules (such as decision table, decision tree, when, and map value). This validation displays the input values for testing the rule and the result that is generated by the rule. 

For more information about configuring a decision result validation, see Configuring decision result assertions.

Case instance count

This validation can be configured by users only for unit testing the flow and case type rules, and to verify the number of cases that were created when the case type or flow ran.

For more information on how to configure a case instance count validation, see Configuring case instance count assertions.

Case status

This validation can be configured by users only for unit testing the flow and case type rules, and to verify the status of the case. 

For more information about configuring a case status validation, see Configuring case status assertions.

Assigned to

This validation can be configured by users only for unit testing of flow and case type rules, and to verify if an assignment is routed to the appropriate work queue or operator.

For more information about configuring the assigned to validation, see Configuring assigned to assertions.

Attachment exists

This validation can be configured by users only for unit testing the flow and case type rules, and to verify that the flow or case type has an attachment of File, Note (attached by using the Attach Content shape), or Email (attached by using the Send Email shape) types attached.

For more information about configuring the attachment exists validation, see Configuring attachment exists assertions.

Check your knowledge with the following interactions.