Functional testing is categorized into two types:
- Product Functional Testing
- Custom Functional Testing
Product Functional Testing
Product Functional Tests are a set of stable HTTP integration tests (ITs) around core functionality in AEM (for example, authoring and replication) that prevent customer changes to their application code from being deployed if it breaks this core functionality.
Product Functional Tests run automatically whenever a customer deploys new code to Cloud Manager and cannot be skipped.
Refer to Product Functional tests for sample tests.
Custom Functional Testing
The Custom Functional testing step in the pipeline is always present and cannot be skipped.
However, if no test JAR is produced by the build, the test passes by default.
The Download Log button allows access to a ZIP file containing the logs for the test execution detailed form. These logs do not include the logs of the actual AEM runtime process – those can be accessed using the regular Download or Tail Logs functionality. Refer to Accessing and Managing Logs for more details.
Writing Functional Tests
Customer-written functional tests must be packaged as a separate JAR file produced by the same Maven build as the artifacts to be deployed to AEM. Generally this would be a separate Maven module. The resulting JAR file must contain all required dependencies and would generally be created using the maven-assembly-plugin using the jar-with-dependencies descriptor.
In addition, the JAR must have the Cloud-Manager-TestType manifest header set to integration-test. In the future, it is expected that additional header values will be supported. An example configuration for the maven-assembly-plugin is:
<build> <plugins> <!-- Create self-contained jar with dependencies --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>3.1.0</version> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <manifestEntries> <Cloud-Manager-TestType>integration-test</Cloud-Manager-TestType> </manifestEntries> </archive> </configuration> <executions> <execution> <id>make-assembly</id> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plugin> </plugins>
Within this JAR file, the class names of the actual tests to be executed must end in IT.
For example, a class named com.myco.tests.aem.ExampleIT would be executed but a class named com.myco.tests.aem.ExampleTest would not.
The test classes need to be normal JUnit tests. The test infrastructure is designed and configured to be compatible with the conventions used by the aem-testing-clients test library. Developers are strongly encouraged to use this library and follow its best practices. Refer to Git Link for more details.
Local Test Execution
As the test classes are JUnit tests, they can be run from mainstream Java IDEs like Eclipse, IntelliJ, NetBeans, and so on.
However, when running these tests, it will be necessary to set a variety of system properties expected by the aem-testing-clients (and the underlying Sling Testing Clients).
The system properties are as follows:
- sling.it.instances - should be set to 2
- sling.it.instance.url.1 - should be set to the author URL, for example, http://localhost:4502
- sling.it.instance.runmode.1 - should be set to author
- sling.it.instance.adminUser.1 - should be set to the author admin user, e.g. admin
- sling.it.instance.adminPassword.1 - should be set to the author admin password
- sling.it.instance.url.2 - should be set to the author URL, for example, http://localhost:4503
- sling.it.instance.runmode.2 - should be set to publish
- sling.it.instance.adminUser.2 - should be set to the publish admin user, for example, admin
- sling.it.instance.adminPassword.2 - should be set to the publish admin password