Understanding Automated Forms Testing with AEM Forms understanding-automated-forms-testing-with-aem-forms

AEM 6.3 Forms introduces the capability to let users create test cases within AEM for Adaptive Forms using Calvin SDK built on top of the hobbes.js framework.

Transcript
Hey guys, in this video I would - like to show you how to create automated test cases for - AEM 6.3 adaptive forms. To create automated - testing, we use Hobbes.JS, which is a javascript UI testing framework for a - AEM related products. I have an AEM 6.3 instance - running on my local machine at port number 4502.
From the AEM home page, let’s navigate to AEM forms - and select Forms & Documents.
I have a form already - created for demo purpose. Let’s open the demo - form to edit it.
You can notice that the demo - form has three sections, each section collects - information from the user using the form fields. Some of the fields are mandatory - and some are not required. But every code deployment - curating needs to make sure that, all form submissions are going - through fine as a sanity check. For some of the verticals - like Finance and Health, it is important to - make sure we collect all the required - information from the user and all forms on submissions - are successful. Often, QA needs to make sure that the form submissions - are going through fine, by manually entering the values and need to create logs - for each test cases. Manual testing is time consuming, - human error prone and we need to keep a record of test - cases that failed and that past.
AEM 6.3 introduces the capability to automate the test cases for - AEM forms using Calvin SDK. Note that, Calvin SDK is - available from AEM 6.3 onwards. In this section, we are going - to create test cases against for our demo form. We will be writing our test - cases again these fields later. Navigate to CRX/DE client and then - go to the client folder under etc.
To explain these steps to - create an automated test, we have already created a clientlib for Calvin SDK settings - under etc clientlib. Click on the node and you - can notice that the node type is cq:ClientLibraryFolder. All test scripts are created and - stored under this ClientLib node. Make sure, you have all the dependencies - added to your Clientlib, also check out the - categories property. Category Property values can later - be used to filter your test cases.
Let’s open the sampleTest.js and check out some of the - test cases, we have written. At this point, we have successfully - registered a javascript file with a clientlib framework. Now, we need to register the - test plus that we are using. Each testsuites can have a - collection of test cases. Each test case can have a - collection of test actions.
In order to create a testsuit, - we need to provide two arguments. First one, is name of the testsuit and the second argument - is a list of options, separated by a comma - and parentheses.
You can see the list - of options available with the attached materials.
Let’s open a new tab and - navigate to AEM homescreen. Click on the tools option, - select Operations and then click on the - Settings option. You can notice all the test defined - for your application, listed here. You can further filter the test - cases that are relevant to us, by using the filter option. On your URL, open the - parameter called filter and copy paste the - value from CRX/DE. The value used here is - from the Category Property under your Calvin SDK - testing parent folder. Without the “granite.testing. - calvin.test group”. To filter your route test and apply it to your URL - filter parameter value.
After filtering your test cases, you can notice our Demo - Form Validation testsuit. Currently, there is no test - case that is ready to be run. Let’s navigate back to CRX/DE and add some test cases - to our testsuit. As a QS specialist I - would like to make sure, forms can be really submitted with some valid inputs.
You can also create a testsuit - automate this requirement. So, I have already created a - successful submission test case. You can add a test case - to a certain testsuit using the addTestCase method. Along with that, we - need to provide a name for our test case and list - down the list of actions, we need to perform - under this test case.
Testsuit plus implements chaining - thereby making it easier to keep track of all the test cases and it’s execution - in a specific order. Let’s take a look at - our first test case and see what we are - trying to achieve here.
On running the successful - submission test case. A test is directed to the URL - provided in the navigate to action.
FillInput and typeInput - functions are used to input user details into - the form elements. .click function is used to invoke - a submission, or an user action. These actions are mostly based on same principle where we - select a down element, using J Curie selectors and check for element attributes - and perform an user action on it.
Similar to the above test case they can have another test case - called a Form Field Validation. To test of the form - submission is unsuccessful, invalid or empty field values.
Save your changes and let’s - navigate to hobbes testing UI. On our first load, we noticed that - the demo form validation testsuit, with no test cases added to it. Now, we have added two test cases, so let’s refresh the page - to notice our changes.
Notice, the number of test cases added to the demo form validation - testsuit within the brackets. Let’s expand the testsuit and you - can notice the list of test cases. We have two options, either to run - our tests under this testsuit, or navigate to CRX/DE - to make changes to it.
You can also individually - run the test cases. Let’s go ahead and run all test - cases and see what happens.
All the test cases - did run successfully and you can notice the - status of each test cases, either with a green check - icon, or Red Cross icon.
Let’s click on the Successful - Submission test case and check out the result. You can also check out the - list of user action performed, by clicking on the - Successful Submission under the results section.
Using this method, you can - automate differenttest cases for your AEM forms and - automate testing. -
NOTE
Adaptive Forms automated testing capability is available with AEM 6.3 onwards
recommendation-more-help
8de24117-1378-413c-a581-01e660b7163e