Anatomy of a Pega unit test

In a Pega Platform™ application, the smallest unit is an individual rule. The purpose of unit testing a Pega Platform application is to verify the functional behavior of the application rules at a unit level. When compared with the unit testing tools available in the market that work on testing the source code, Pega unit testing involves working with individual rules and not the source code, thus making it an easy to use tool for users.

For example, you ensure that a data page or a decision table works as expected in isolation. It is much easier and faster to test the various permutations and outputs of these rules through unit testing than other forms of testing. 

Automated unit testing of a Pega Platform application involves the following actions:

• Creating unit-test cases for each rule.
• Logically grouping multiple test cases into test suites.
• Running tests regularly.
• Verifying results and taking corrective actions.

By successfully unit testing individual rules of the application, users are confident that these rules work correctly. Most application tests are unit tests as part of application testing best practices. Unit testing reduces the need to write multiple integrations and end-to-end tests that have heavy maintenance overhead and are difficult to debug when users encounter errors.

In the following example, consider an application that is built on Pega Platform, Hardware Inventory Management, which involves tracking and managing the physical components of an IT enterprise such as laptops, routers, servers, and other devices. One of the application features that are available to users is to view the list of items in the inventory based on the type of item and its vendor name. 

For example, the inventory includes multiple laptops. Some laptops are from a vendor named ABC, while some are from a different vendor XYZ. The inventory also lists routers and other devices from different vendors. To show the list of items present in the inventory, a UI section in the application displays the list of items on the screen according to the user's inputs (item type and Vendor name). In the background, this UI is sourced by a data page, which internally calls a report definition rule that fetches the items list from the database. 

The following figure depicts the flow of invocation of these different rules.

If the user wants to view the list of all Laptops that are available in the inventory from vendor ABC, the user provides two inputs in the UI as shown in the following table:

The user then clicks Submit to view the list. The requirement is to display only ABC Laptops. However, the user can view all the different items (laptops, routers, and other devices) and their vendors. 

Now, the user is aware that the functionality is faulty. With the help of a Pega unit test, the user can identify the issue as soon as the functionality fails by running test cases regularly. The user creates a meaningful Pega unit test for the data page where Laptop is passed as the value of the ItemType input parameter (of the data page) and ABC as the value for the VendorName input parameter. Adding appropriate assertions on the pxResults (output list of the data page) list ensures that only ABC Laptops are listed as the output of the data page. For example, in this case, each item ID in the pxResult list starts with Laptop_AB. 

If the data page lists other item types or laptops from other vendors as output, the assertions in the Pega unit test fail. The results indicate that the functionality is working incorrectly and requires attention.

While performing any testing, the user supplies the input data. The actual output of the tested code is compared with the expected output to determine if a test has passed or failed. 

The following figure shows the process flow of a Pega unit test case. As part of the test flow, the test data is initially setup for the rule, after which the rule executes taking the necessary input data from the setup and produces the output. After the rule execution is completed, configured validations are evaluated. Depending on the results of the validations, the test is either marked as pass or fail. Once the test is marked as pass or fail, the configured clean-up activities are executed. This cleans up all the test data that is created as part of the test case execution.

Check your knowledge with the following interaction.