Expression rule test cases enable unit testing with minimal overhead by reducing the time required to test while increasing code quality. Because expression rules have a wide variety of uses, creating meaningful test cases will speed up unit, regression, and exploratory testing. Use the following guidelines to create test cases for your expression rules that will result in greater code coverage for your application. The first section provides guidelines for creating useful test cases, and the following sections explain types of expression rule test cases in greater detail with Appian examples.
The following guidelines apply to expression rules which output a value:
When creating test cases, consider the two types of test cases: coverage tests and error handling tests. Every expression rule should always have at least one of each kind of test case.
A coverage test ensures the rule inputs result in the intended output. In other words, an area of the rule has been sufficiently “covered” via a test case.
Set inputs to expected values.
An error handling test ensures the expression rule has proper error handling.
Set inputs to values that would typically break the rule.
If your expression rule has a limited number of outcomes, use the below examples to guide your test case creation. Use test!output to assert that the output is equal to the value you expect. Each outcome should have a test case and corresponding assertion.
If your expression rule has an unlimited number of outcomes, use the below examples to guide your test case creation. Use test!output where it makes sense to ensure the output is equal to the expected value.
Error handling test cases should be created based on the functions and inputs of the rule. All rules should have null handling test cases (unless already covered by a parent rule), while other error handling scenarios should be determined at the Designer’s discretion. All error handling cases should have the test output match an asserted output.
Note: Expression rules containing queries should only include the a!queryEntity() function. Any expressions to manipulate the data or output different values based on the query results should be done in separate expression rules, using the results of the query as a rule input. This allows flexibility to assert that the manipulation or conditional output operates correctly without relying on transaction data that can change across Appian environments.
Figure N : Sample Expression Rule
Figure M : Sample Test Cases
These are test cases a user could have set up for the rule provided in Figure N. The first box contains Coverage Tests. They provide code coverage by testing with expected inputs and outputs. The second box contains Error Handling Tests. These tests are staged with inputs that would typically result in a denominator of 0. Finally, the third box contains Null Handling Tests. This is another specific type of error handling tests. They are used to verify that our rule can properly handle null inputs. Note that more than one was required for this rule.
Test cases make it easier and faster to regression test. Before making a change to an existing expression rule, run all existing test cases within the rule and resolve any that have failed. After making the change, add coverage and error handling test cases to test the change. Finally, run all test cases to ensure the update didn’t break any existing cases.
Before a deployment, run the Automated Rules Testing Application (ART) in the target environment (non-production) to ensure all test cases work as expected before the deployment. If any rules do not work, resolve the issues in the lower environment prior to the deployment. After the deployment, re-run ART in the target environment to ensure all new and old test cases work as expected.
Note: These examples are not all-encompassing. Best judgement should be used to determine what cases are required.
© 2023 Appian. All rights reserved.