Introduction
Discover the quality gates available in the AEM as a Cloud Service deployment process and the various types of built-in functional testing. Learn how you can contribute and optimize their use within the framework of a comprehensive testing strategy.
About functional testing
The following diagram provides a high-level overview of the available pipelines in the context of an overall testing strategy and the AEM as a Cloud Service deployment process.
Purpose of functional testing
The purpose of the AEM Cloud Service deployment pipelines is to facilitate robust and secure deployments at various stages of your development and AEM product release lifecycle. These pipelines incorporate multiple quality gates at different levels to ensure the integrity and safety of deployments for both your AEM application changes and AEM product updates.
Adobe provides several built-in quality gates, while others require your intervention for implementation and configuration. These quality gates are versatile, applying at various lifecycle stages and integrating directly into your development setup and CI/CD processes.
The built-in quality gates primarily validate the functionality of the AEM product within the context of your AEM application. In contrast, the custom quality gates you set up are designed to verify that your application’s critical features and user interactions perform as intended. Collectively, these two sets of quality gates work together to ensure robust and secure automated deployments for both your code modifications and AEM product updates.
It is important to note that these quality gates are not intended to be a comprehensive testing framework for your entire testing strategy. The AEM product is subjected to extensive testing before entering the AEM cloud service deployment process. Similarly, your application should already be of high quality before it reaches the deployment phase. This approach ensures that the quality gates focus on their primary objective of safeguarding the deployment process, rather than being a substitute for a full testing regimen.
Quality gates in testing
The following diagram provides a detailed view of available quality gates and their use in the overall testing strategy and the AEM as a Cloud Service deployment process.
Summary customer provided quality gates
| Unit Tests | Custom Functional Tests | Custom UI Tests | Customer Validations | Manual Testing | |
|---|---|---|---|---|---|
| Production Pipeline | Yes Blocking | Yes Blocking 60m Timeout | Yes Blocking 30m Timeout | No | No |
| Non-Production Pipeline | Yes Blocking | Opt-In Blocking 60m Timeout | Opt-In Blocking 30m Timeout | No | No |
| Adobe Internal Validation | Yes Blocking | Yes Blocking 60m Timeout | Yes Blocking 30m Timeout | No | No |
| Customer CI/CD | Yes | Yes | Yes | Yes | Yes |
| Customer Local Developer | Yes | Yes | Yes | Yes | Yes |
Unit test
You are encouraged to provide the unit tests for your AEM application, which are the foundation of every testing strategy. They are intended to run fast and often and give early and fast feedback. They are tightly integrated into the developer workflows, your own CI/CD and the AEM cloud service deployment pipelines.
They are implemented using JUnit and are executed with Maven. See the core module of the AEM Project Archetype for an example unit test for AEM and getting started.
Code quality
This quality gate is configured out-of-the-box and runs static code analysis on your AEM application code.
See Code Quality Testing and Custom code quality rules for more information.
Product tests
Product functional tests are stable HTTP integration tests (ITs) for core AEM functionality, including authoring and replication tasks. Adobe provides and maintains them out-of-the-box. They are intended to prevent changes to custom application code from being deployed if it breaks core functionality in the AEM product.
They use JUnit for implementation, run with Maven, and rely on the official AEM Testing Clients. The product test suite is maintained as
an open-source project, follows best-practices and can be considered a good starting point for the implementation of your tests.
Custom functional tests
Similar to the product tests, customer functional tests are HTTP integration tests (ITs) implemented with JUnit, run using Maven, and built on top of the official AEM Testing Clients.
NOTETo maintain efficient pipeline runs, Adobe advises focusing on key features and primary user interaction flows, aiming for a functional test runtime of around 15 minutes or less. Full functional test suites that exceed this time should be executed as part of the general customer validation pipelines during the development process.
See open-sourced product tests or the it.tests module of the AEM Projects Archetype for examples.
See Java Functional Tests for more information.
Custom UI tests
To maximize risk control for your customer-specific development, Adobe encourages you to capture critical UI tests into AEM as a Cloud Service. Keep them limited but focused on maximizing their impact on the customer experience.
The tests are packaged in a Docker image - designed to be as volatile as possible (with support for Cypress, Playwright, Selenium, Java, and JavaScript). They follow the same characteristics and purposes like the custom functional tests.
NOTETo keep pipeline executions efficient, Adobe recommends focusing on key features and main user interaction flows. Full UI test suites that exceed this quality gate should be executed as part of the general customer validation pipelines. Incorporate them into the customer’s development process.
See open-sourced example tests or the ui.tests module of the AEM Projects Archetype for examples.
See Custom UI Testing for more information.