Prueba funcional de Java™

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

Introducción a las pruebas funcionales getting-started-functional-tests

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.

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

Escribir pruebas funcionales personalizadas writing-functional-tests

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 functional-tests-structure

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.

Requisitos previos prerequisites

Dependencias

Los próximos cambios en la infraestructura en contenedores para ejecutar pruebas funcionales requieren actualizar la biblioteca aem-cloud-testing-customers en sus pruebas funcionales personalizadas a la versión 1.2.1 o superior. Asegúrese de que la dependencia del archivo it.tests/pom.xml se actualice en consecuencia.

<dependency>
   <groupId>com.adobe.cq</groupId>
   <artifactId>aem-cloud-testing-clients</artifactId>
   <version>1.2.1</version>
</dependency>

Ejecución de pruebas locales local-test-execution

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

Ejecutar en un IDE running-in-an-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 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:

Ejecución de todas las pruebas con Maven using-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>