Prueba funcional de Java™

Última actualización: 9 de octubre de 2024

Creado para:

  • Administrador
  • Desarrollador

Obtenga información sobre cómo escribir pruebas funcionales de Java™ para AEM as a Cloud Service

Introducción a las pruebas funcionales

Al crear un nuevo repositorio de código en Cloud Manager, se crea una carpeta it.tests automáticamente con casos de prueba de ejemplo.

NOTE
Si el repositorio se creó antes de que Cloud Manager creara automáticamente carpetas it.tests, también puede generar la última versión utilizando el Arquetipo de proyecto de AEM.

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

  1. Desarrolle sus casos de prueba.
  2. Ejecute las pruebas localmente.
  3. Confirme su 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. AEM Consulte Tipo de archivo del proyecto de para ver 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. Esta configuración 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, esta versión 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>
</build>

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 JUnit normales. La infraestructura de la prueba está diseñada y configurada para ser compatible con las convenciones utilizadas por la biblioteca de prueba aem-testing-clients. Se recomienda a los desarrolladores que utilicen esta biblioteca y sigan sus prácticas recomendadas.

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

TIP
Vea este vídeo sobre cómo puede usar las pruebas funcionales personalizadas para mejorar su confianza en sus canalizaciones de CI/CD.