Automated Testing for Expression Rules

Overview

This article provides guidance on how to use automated testing for expression rules. Learn how you can use automated testing to test your rules more quickly and efficiently.

Appian provides a way to perform batch testing of test cases from outside of the expression rule designer. This can be all test cases within a system, or restricted to all test cases within select applications. Batch test runs can be started from process models, SAIL interfaces, or web APIs. See Common Uses for additional details.

There are two new smart services that start the test run:

  1. Start Rule Tests (Application) - Smart Service
  2. Start Rule Tests (All) - Smart Service

After starting a test run, the time it takes is dependent on the total number of test cases. You can check on the status of the test run with the a!testRunStatusForId() function. Once the test run is complete, you can retrieve the results with the a!testRunResultForId() function. Check out Parsing Batch Test Results for Expression Rules.

Usage Scenarios

Expression rules are one of the smallest parts of an Appian application and thus they provide you with a way to perform unit testing for much of the logic in your applications.

We recommend that all expression rules that are important and reused across your applications have test cases to provide confidence that changes to application logic do not unexpectedly break important scenarios.

Depending on your needs, you can start these tests based on an event, such as the end of a sprint, or before a major deployment to your test environment.

Application testing at the end of a sprint

During development, a team of designers work in adding new functionality to one or more applications. Because changes to an expression rule may have implications in other parts of the application, it is recommended to run a test on all applications that had changes at the end of the sprint. Doing this ensures the test is executed more quickly than when executing a system test in an otherwise cluttered environment. The Start Rule Tests (Applications) - Smart Service allows you to start a test run for all expression rules in a system.

Regression testing before a major deployment

Before releasing a new version of your application, you want to make sure that new changes don't break functionality in other applications as some of your expression rules may be shared with applications you didn't modify or had access to during development.

It is recommended to perform regression testing on all expression rules in the system after you deploy all changes to your test environment. By doing so, you can find out whether dependent expression rules get affected by changes to the application you are about to release. The Start Rule Tests (All) - Smart Service allows you to start a test run for all expression rules in a system.

Common Uses

There are different ways in which you can initiate automated testing for expression rules. Within Appian, you can use a SAIL interface embedded in a report; or a process model, which is exposed to users as an action.

Additionally, you can integrate with external systems by creating web APIs to wrap around the testing smart services and functions, and invoke them from outside of Appian.

Testing in Appian

SAIL Interface

If you want to provide your users with the ability to run tests for expression rules for an application or system, you can create a SAIL interface with new buttons to Start an application test, and Refresh the page to see the status of the test run, and display statistics about the test.

The screenshot below shows statistics such as the time spent executing the test cases, who executed the test, and how many test cases failed or completed successfully.

It also allows you to see statistics on the expression rules that are part of the application, and drill down to the test cases that failed by clicking on links provided in the grid, under the Details heading.

For additional details on the data types used to store test results, see Parsing Batch Test Results for Expression Rules for additional details.

This approach works if you are running a test for a few applications. However, if you have thousands of expression rules, you may want to create an action instead so you don't have to wait a long time before the test finishes executing.

Process Model

You can perform automated testing on expression rules using an action. This approach is recommended if you have thousands of expression rules to test, either in a few applications or across the entire system. By using an action, you don't have to wait until the test is finished and instead, configure the action to send an email upon completion of the test; and include a grid summary of the expression rules that contain failed test cases, including:

  • The expression rule name
  • The username that last modified the rule
  • A link to the expression rule, which will open the rule in a browser so you can immediately address the root cause of the failure

Integrating with External Systems

You can perform automated testing on expression rules from external systems. For example, you can create a Jenkins project that can run a test of all expression rules in a system, or one or more applications.

This integration is possible by creating web APIs to wrap around the testing smart services and functions. These web APIs can then be invoked from a project in Jenkins, using a gradle task to start a test run, check the status of the test run until the test is complete, and then retrieve the results of the test in an xml file representation of the TestRunResult data type.

This XML can then be transformed to the Junit format so it can be interpreted as a test result by Jenkins and displayed in a report similar to the one shown below.

See Running Automated Tests on Expression Rules from Jenkins for a recipe on how to accomplish the above.

See Also

FEEDBACK