Overview of test automation with Pegaunit framework in platform
Pegaunit framework helps users to create automated unit tests for their applications. This framework is available out of the box and there is no need to purchase a separate license or do any configuration to work with it.
To start with, just designate a rule-set in your application stack, to store the created test cases. Make sure this rule set is used only to store test cases but not the functional rules of the application, to ensure this can be removed from the stack during packaging. That’s it. You are ready to work with the framework.
Currently this framework supports 13 rule types i.e. you can create automated tests only for the rules of these 13 rule types.
Steps to create & run an automated test
1. Run the rule you want to create a test case for
- Open the rule and manually run it first
- Once you are satisfied with the output, you are ready to create an automated test for it
2. Convert the run to a test by selecting “Convert to test” option on the run window
3. Give proper description, explaining what the test is for
4. Add steps to setup test data
- You can go to the “Setup/Clean-up” tab of the test case to define steps that would generate the necessary test data for the test to execute the rule
- There are multiple options to create test data. You can run a data transform, create and load objects, load data pages, run an activity, copy pages from clipboard
5. Add steps to clean-up test data after the test is completed
- All data pages, work pages that were loaded/created would get automatically removed at the end of each test
- You can add steps to remove any other data. A data transform or an activity can be run to perform necessary clean-up
6. Create necessary validations to verify actual output against expected output
- There are multiple validation options possible to verify the test output
- Any number of validations can be added in a test
- You can only validate (create validations for) the data that is available on the clipboard
- Validations that are supported are,
7. Save the test case in the designated rule-set by giving proper label
8. Run the test case
- You can run the test case by doing Actions -> Run
- Test would either pass or fail. You can view the test results to correct any failures
- You can also view the history of test results for a test case
View & manage test cases of an application
There is a landing page for automated unit testing which shows all the test cases for the application. You can use various filters available on this page to see the required test cases and their results/status. You can also run test cases in bulk from this page.
In case you want to view & run all the test cases related to a particular rule, then you can visit the “Test cases” tab of the rule which displays all the test cases created for that rule. You can do a bulk run from this place.
Other important features:
Grouping test cases into test suites
Test cases can also be grouped into various test suites using Pegaunit test suites feature. There is a separate landing page to create and maintain test suites of Pegaunit tests. You can either select test cases from test case landing page and create a suite which includes them or create an empty suite and add test cases to it.
It is also possible to include test suites inside test suites.
A test suite can also be used for performance testing. You may define a performance benchmark using "Expected max runtime" option and configure to fail the test suite if the performance validation fails. This bench mark is calculated against the total time taken by all the test cases & test suites included in the test suite.
Quarantine (Disable) test case:
A test case can be quarantined if it is repeatedly failing and it needs to be disabled till it is fixed. There is an option to “Disable” a test in the rule form of the test case. If it is disabled, it will not be executed through a test suite or through the rest service that executes it. You can still run the test by opening the test and doing Actions -> Run.
Copy a test case:
You can save a test case can with a different name and modify the validations to create multiple test cases for a rule easily. All the validations, setup/clean-up activities configured in the original test case would be copied to new test case in this case.
Apart from the filters that are seen on the test case landing page, you can use some additional filters to select test cases created by a particular operator or created between two dates.
Informational guardrail warning:
It is advised to created automated unit tests for every rule that is supported by Pegaunit, to ensure good coverage for the application and to do quick regression in case of any changes to the rules. When there is no test case exists for a rule, there would be an informational guardrail warning gets generated for the rule. This warning doesn’t impact the overall guardrail score of the application.
Service to run application unit tests in a pipeline:
This framework provides a REST service which can be called from any external system to access and execute all the test cases of an application. This service has the capabilities to execute,
- All tests of an application
- All tests of an application associated to an access group
- Param: AccessGroup=<access_group_name:access_group_user>
- All tests in a test suite
- Param: TestSuiteID=<pxInsName>
Application quality settings:
By default, you would be able to see & execute all the test cases and test suites belong to the logged in application. If you want to work with the tests of multiple applications in the stack, then you can use application quality settings landing page to select required applications. In this page, you can also set few other things related to how test cases should be treated.
Other points to note:
- Both test case & test suite are rules them selves and they behave as any other rule in the system. Example: Rule resolution, Locking
- When you run test cases or test suites in bulk, they run sequentially i.e. one after the other but not in parallel
- Every test case runs in it’s own thread and doesn’t impact the results of any other tests that are run in parallel
How to work with few key requirements:
- How to setup test data
- How to validate parameters
- How to test activities with DB operations
- How to run a rule on a different page than the run record primary page
- How to simulate call to a data page
- How to integrate PegaUnit tests into CI-CD pipeline
- Best practices for authoring PegaUnits