Overview

Adaptive forms are integral to your customer interactions. It is important to test your adaptive forms with every change you make in them, such as while rolling out a new fix pack or changing a rule in the form. However, functional testing adaptive forms and every field in them may be tedious.

Calvin allows you to automate testing of your adaptive forms in the web browser. Calvin utilizes Hobbes's user interface for running the tests and provides the following tools:

A JavaScript API for creating tests.

A user interface for running tests.

Using Calvin, you can create test cases in CRXDE and run UI tests directly in the web browser to thoroughly test your adaptive forms' following aspects:

Adaptive form aspect to test

Description

Prefill experience of an Adaptive Form

Is the form being prepopulated as expected based on the type of data model?

Are the default values of form objects being prefilled as expected?

Submit experience of an adaptive form

Is correct data being generated on submit?

Is the form being re-validated on the server during submit?

Is the submit action configured for the form being executed?

Expression Rules

Are the expressions associated with form objects, such as calculate, visible, execute scripts after exiting a field, being executed after performing the relevant UI operations?

Validations

Are field validations executing as expected after performing the operations?

Lazy Loading

On click of tabs (or any navigation item of a panel), is the HTML being fetched from server as per lazy loading configuration?

Prerequisites

Example: Create a test suite for an adaptive form using Hobbes as testing framework

The following example walks you through creation of a test suite for testing multiple adaptive forms. You need to create a separate test case for each form that you need to test. By following steps similar to the following ones and modifying the JavaScript code in step 11, you can create your own test suite to test your adaptive forms.

Go to CRXDE Lite in your web browser: http://[server]:[port]/crx/de.

Right-click the /etc/clientlibs subfolder and click Create > Create Node. Enter a name (here afTestRegistration), specify the type of node as cq:ClientLibraryFolder, and click OK.

The clientlibs folder contains the registration aspect of your application (JS and Init). It is recommended that you register all Hobbes test suites objects specific to a form in the clientlibs folder.

Specify the following property values in the newly created node (here afTestRegistration) and then click Save All. These properties help Hobbes recognize the folder as a test. To reuse this client library as a dependency in other client libraries, name it as granite.testing.calvin.tests.

The above code creates a test suite named Adaptive Form - Demo Test. To create a test suite with a different name, change the name accordingly.

Click Create > Create Node to create a node under the clientlib folder for each form that you want to test. This example uses a node named testForm to test an adaptive form named testForm.Specify the following properties and click OK:

Name: testForm (your form name)

Type: cq:ClientLibraryFolder

Add the following properties to the newly created node (here testForm) to test an adaptive form:

Property

Type

Value

categories

String[]

granite.testing.hobbes.tests, granite.testing.hobbes.tests.testForm

dependencies

String[]

granite.testing.calvin.tests

Opmerking:

This example uses a dependency on the client lib granite.testing.calvin.tests for better management. This example also adds a client lib category, "granite.testing.hobbes.tests.testForm" to reuse this client lib, if necessary.

Right-click the folder you have created for the test form (here testForm) and select Create > Create File. Name the file scriptingTest.js and add the following code to the file and click Save All.

To use the following code to test another adaptive form, change the path and name of the form in navigateTo (lines 11, 36, and 62) and the respective test cases. For more information on APIs for testing different aspects of forms and form objects, see Calvin APIs.

You can also install the package in the attached file SampleTestPackage.zip to achieve the same results as by the steps explained in Example: Create a test suite for an adaptive form using Hobbes as testing framework.

Testing Your UI Using Automated Tests

Running a Single Test Suite

Tests Suites can be run individually. When you run a Test Suite, the page changes as the Test Cases and their Actions are executed and the results appear after completion of the test. Icons indicate the results.

A checkmark icon indicates a passed test:

An "X" icon indicates a failed test:

To run a Test Suite:

In the Tests panel, click or tap the name of the Test Case that you want to run to expand the deatils of the Actions.

Click or tap the Run tests button.

The placeholder is replaced with page content as the test executes.

Review the results of the Test Case by tapping or clicking the description to open the Result panel. Tapping or clicking the name of your Test Case in the Result panel shows all details.

The steps for testing your AEM adaptive forms are similar to steps for testing your AEM UI. For more information on testing your adaptive forms, see the following topics in Testing Your UI:

Viewing Test Suites

Running Multiple Tests

Glossary

Term

Description

Test suite

A test suite is a collection of related test cases.

Test case

A test case represents a task that a user performs using your UI. Add test cases to your test suite to test the activities that users perform.

Actions

Actions are methods that perform a gesture in the UI, such as clicking a button or filling an input box with a value.

The methods of the hobs.actions.Asserts, hobs.actions.Core and hobs.utils.af classes are actions that you can use in your tests. All actions execute synchronously.

Author or publish environment

In general, forms can either be tested in author or publish environment. In case of publish environment, by default, the access to execute the test is restricted. This is because all the client libraries related to test runner lies inside the /libs in the JCR structure.