Pruebas funcionales

Obtenga información sobre los tres tipos diferentes de pruebas funcionales integradas en el proceso de implementación de AEM as a Cloud Service para garantizar la calidad y fiabilidad de su código.

Información general

Hay tres tipos diferentes de pruebas funcionales en AEM as a Cloud Service.

• Prueba funcional del producto
• Prueba funcional personalizada
• Prueba de IU personalizada

Para todas las pruebas funcionales, los resultados detallados de las pruebas pueden descargarse como un .zip archivo mediante el botón Descargar registro de generación en la pantalla de información general de la generación como parte del proceso de implementación.

Estos registros no incluyen los registros del proceso del tiempo de ejecución de AEM real. Para acceder a esos registros, consulte el documento Acceder y administrar registros para obtener más información.

Tanto las pruebas funcionales del producto como las pruebas funcionales personalizadas de ejemplo se basan en la los clientes de prueba de AEM.

Prueba funcional del producto

Las pruebas funcionales del producto son un conjunto de pruebas de integración (TI) HTTP estables de funcionalidad central en AEM como las tareas de creación y replicación. Estas pruebas las mantiene Adobe y su objetivo es evitar que se implementen cambios en el código de aplicación personalizado si rompen la funcionalidad principal.

• Canalizaciones de producción: Las pruebas funcionales del producto se ejecutan automáticamente cada vez que implementa un nuevo código en Cloud Manager y no se pueden omitir.
• Canalizaciones que no son de producción: Las pruebas funcionales de producto se pueden seleccionar de forma opcional para que se ejecuten siempre que ejecute la canalización que no sea de producción.

Las pruebas funcionales del producto se mantienen como un proyecto de código abierto. Consulte pruebas funcionales del producto en GitHub para obtener más información.

Prueba funcional personalizada

Aunque la prueba funcional del producto está definida por Adobe, puede escribir sus propias pruebas de calidad para su propia aplicación. Esto se ejecutará como prueba funcional personalizada como parte del canalización de producción o opcionalmente canalización sin producción para garantizar la calidad de su aplicación.

Las pruebas funcionales personalizadas se ejecutan tanto para implementaciones de código personalizado como para actualizaciones de push, lo que hace especialmente importante escribir buenas pruebas funcionales que impidan que los cambios en el código de AEM rompan el código de la aplicación. El paso de prueba funcional personalizada siempre está presente y no se puede omitir.

Prueba de IU personalizada

La prueba de IU personalizada es una característica opcional que le permite crear y ejecutar automáticamente pruebas de IU para sus aplicaciones. Las pruebas de interfaz de usuario son pruebas basadas en Selenium empaquetadas en una imagen Docker para permitir una amplia selección de idiomas y marcos como Java y Maven, Node y WebDriver.io, o cualquier otro marco y tecnología creados en Selenium.

Consulte el documento Pruebas de IU personalizadas para obtener más información.

Introducción a las pruebas funcionales

Tras la creación de un nuevo repositorio de código en Cloud Manager, una it.tests se crea automáticamente con casos de prueba de ejemplo.

Una vez que tenga el contenido de la variable it.tests carpeta, puede utilizarla como base para sus propias pruebas y, a continuación:

1. Desarrolle sus casos de prueba.
2. Ejecute las pruebas localmente.
3. Confirme el código en el repositorio de Cloud Manager y ejecute una canalización de Cloud Manager.

Escribir pruebas funcionales personalizadas

Las mismas herramientas que utiliza Adobe para escribir pruebas funcionales de productos se pueden usar para escribir las pruebas funcionales personalizadas. Utilice las pruebas funcionales del producto en GitHub como ejemplo de cómo escribir las pruebas.

El código para la prueba funcional personalizada es el código Java ubicado en la carpeta it.tests del proyecto. Debe producir un único JAR con todas las pruebas funcionales. Si la generación produce más de un JAR de prueba, el JAR seleccionado no es determinista. Si no produce ningún JAR de prueba, el paso de prueba se aprueba de forma predeterminada. Consulte el arquetipo del proyecto AEM para pruebas de ejemplo.

Las pruebas se ejecutan en una infraestructura de pruebas mantenida por Adobe que incluye al menos dos instancias de autor, dos instancias de publicación y una configuración de Dispatcher. Esto significa que las pruebas funcionales personalizadas se ejecutan con toda la pila de AEM.

Estructura de pruebas funcionales

Las pruebas funcionales personalizadas deben empaquetarse como un archivo JAR independiente producido por la misma generación de Maven que los artefactos que se van a implementar en AEM. Generalmente sería un módulo de Maven separado. El archivo JAR resultante debe contener todas las dependencias requeridas y se crearía generalmente con el maven-assembly-plugin jar-with-dependencies descriptor.

Además, el JAR debe tener el Cloud-Manager-TestType encabezado de manifiesto definido como integration-test.

El siguiente es un ejemplo de configuración para el maven-assembly-plugin.

<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>

Dentro de este archivo JAR, los nombres de clase de las pruebas reales que se van a ejecutar deben terminar en IT.

Por ejemplo, una clase denominada com.myco.tests.aem.it.ExampleIT se ejecutaría, pero una clase denominada com.myco.tests.aem.it.ExampleTest no.

Además, para excluir el código de prueba de la comprobación de cobertura del análisis de código, el código de prueba debe estar debajo de un paquete denominado it (el filtro de exclusión de cobertura es **/it/**/*.java).

Las clases de prueba deben ser pruebas JUnit normales. La infraestructura de prueba está diseñada y configurada para ser compatible con las convenciones utilizadas por la aem-testing-clients biblioteca de prueba. Se recomienda encarecidamente a los desarrolladores que utilicen esta biblioteca y sigan sus prácticas recomendadas.

Consulte el aem-testing-clients Repositorio de GitHub para obtener más información.

Ejecución de pruebas locales

Antes de activar pruebas funcionales en una canalización de Cloud Manager, se recomienda ejecutar las pruebas funcionales localmente mediante el SDK as a Cloud Service AEM o una instancia as a Cloud Service AEM real.

Requisitos previos

Las pruebas en Cloud Manager se ejecutarán mediante un usuario administrador técnico.

Para ejecutar las pruebas funcionales desde el equipo local, cree un usuario con permisos de tipo administrador para lograr el mismo comportamiento.

Ejecución en un IDE

Como las clases de prueba son pruebas JUnit, se pueden ejecutar desde IDE de Java convencionales como Eclipse, IntelliJ y NetBeans. Dado que tanto las pruebas funcionales de producto como las pruebas funcionales personalizadas se basan en la misma tecnología, ambas se pueden ejecutar localmente al copiar las pruebas de producto en las pruebas personalizadas.

Sin embargo, al ejecutar estas pruebas, será necesario establecer una serie de propiedades del sistema que espera el aem-testing-clients (y la biblioteca de clientes de prueba de Sling subyacente).

Las propiedades del sistema son las siguientes:

• 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, for example, admin
• sling.it.instance.adminPassword.1 - should be set to the author admin password
• sling.it.instance.url.2 - should be set to the publish 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

Ejecución de todas las pruebas con Maven

1. Abra un shell y vaya a it.tests en el repositorio.

2. Ejecute el siguiente comando proporcionando los parámetros necesarios para iniciar las pruebas con Maven.

mvn verify -Plocal \
    -Dit.author.url=https://author-<program-id>-<environment-id>.adobeaemcloud.com \
    -Dit.author.user=<user> \
    -Dit.author.password=<password> \
    -Dit.publish.url=https://publish-<program-id>-<environment-id>.adobeaemcloud.com \
    -Dit.publish.user=<user> \
    -Dit.publish.password=<password>

Recursos de Business.Adobe.com