Automated testing reduces the amount of manual testing necessary in an Appian application and reduces risk at each stage of the application development lifecycle. Automated testing can be used throughout the Appian application development lifecycle to:
Automated testing should be implemented early in a project to prevent buildup of functionality for which test scripts must be written. The longer a team waits to set up automated testing, the more burdensome it can become to do so. Conversely, if test scripts are written for functionality that is highly likely to change, it can be time-consuming to update them to keep up with changing requirements. So, a project team must work together to achieve a balance between these alternatives by determining when and for what purposes to design automated testing scripts.
It is not recommended to have 100% test coverage of an application through Automated Testing due to the below reasons:
These factors can make it difficult to get a good return on the time investment put into building test scripts to cover all functionality in an application.Given that 100% of the application cannot reliably be validated through automated testing, the core team (developers, PO, QAs) must collaborate in order to identify highest priority items to be addressed. Teams should consider factors such as level of effort to create new automated tests and level of risk in determining where to focus test coverage. Based on this collaboration, the automated testing suite can be incrementally updated to ensure highest value areas are targeted first.
Automated testing is not the same as performance testing. To find more information on performance testing best practices and tools such as JMeter and Loadrunner, see Performance and Load Testing.
The following tools can be used to automate testing for Appian applications. The Tools In Appian section describes automated testing features that come OOTB with Appian, which should be used wherever possible. The External Tools section includes the available tools which were not built for Appian, and the Tools Built for Appian section describes tools built for Appian from external tools to facilitate automated testing in Appian.
Expression Rule Test Cases: Test cases can be configured for expression rules to test outputs with any combination of inputs. These function as automated tests built into the expression rule object. See the documentation for more information and instructions on when and how to use expression rule test cases. By importing the Automated Rule Testing application to an environment, administrators can run all test cases regularly and leverage reporting on failures and successes. This will help identify bugs in expression rules faster, speed up regression testing after rules have changed, and make smoke testing deployments even faster.
These should generally only be used when necessary. Otherwise, it is recommended to use FitNesse For Appian or Appian’s Selenium API with Cucumber (described in the Tools Built for Appian section below) because these are preconfigured to work for Appian applications.
Selenium: Selenium is an automated testing tool that is able to control a web browser. Selenium has two different products: WebDriver and IDE. The WebDriver is a collection of language specific bindings that drive a web browser while the IDE is an add-on to Firefox that is able to record and playback interactions with the web browser.
FitNesse: FitNesse is automated testing software which uses a wiki language and allows for a low barrier to entry and ease of use. FitNesse test scripts and test suites are created in the wiki language that map out to functions written in a development language that wrap a Selenium Webdriver to perform actions on an Appian application.
Cucumber: Cucumber is an automated test tool utilizing Behavior Driven Development (BDD) that allows testers to specify test scenarios in a human readable form. Cucumber can be used to create test scripts in plain language with Gherkin syntax. One benefit of Cucumber is that the Product Owner or business users are able to write test cases without a technical background. These test scripts map to functions in a development language (such as Java or Ruby) that wrap a Selenium Webdriver to perform the specified actions on an Appian application.
Appian has created the following tools to reduce the amount of work required to automate testing of Appian applications.
Appian Selenium API: The Appian Selenium API allows you to run Appian UI tests directly from a JUnit Test Case, create your own Gherkin steps and step definitions with Cucumber, and run tests from any java based test tool of your choice without having to create the necessary xpath for selenium to interact with Appian. When using Cucumber, it is recommended to use this API to customize step definitions to match the business users’ phrasing.
FitNesse for Appian: Appian has written WebDriver fixtures to leverage Selenium and FitNesse to create FitNesse for Appian. This tool is easier to set up than Fitnesse and provides a faster way to build automated tests for Appian applications. This is complemented by the FitFam application, which allows users to create FitNesse test scripts for complex interfaces solely by interacting with the interface.
Cucumber for Appian: Cucumber for Appian is a client-side tool that provides a sample set of step definitions similar to those provided by FitNesse for Appian. Note that these step definitions are not application specific. Features and scenarios written with these sample step definitions will not embrace the Behavior Driven Development (BDD) aspects of Cucumber. Cucumber for Appian is a good starting point for teams not familiar with Cucumber to get familiar with Cucumber before writing their own cucumber step definitions in Java. Additionally, the sample step definitions will allow testers to write a fairly complete set of tests without needing to know Java.
Teams experienced in writing automated tests as code might find the sample step definitions provided by Cucumber for Appian limiting. For example, gherkin syntax does not allow for saving variables between steps or looping. We recommend leveraging the Appian Selenium API to write your own step definitions for testers that want to trade the simplicity of Cucumber for Appian with the power provided by code. Custom Step Definitions in tandem with the Appian Selenium API will allow you to write future proof tests that will work between upgrades and embrace BDD.
For more information, see the Cucumber for Appian Playbook Play