La prueba de IU personalizada es una función opcional que le permite crear y ejecutar automáticamente pruebas de IU para sus aplicaciones.
AEM ofrece un conjunto integrado de Puertas de calidad de Cloud Manager para garantizar actualizaciones sin problemas en las aplicaciones personalizadas. En concreto, las puertas de prueba de TI ya se han creado y automatizado pruebas personalizadas mediante API AEM.
Las pruebas de interfaz de usuario son pruebas basadas en Selenium empaquetadas en una imagen Docker para permitir una amplia variedad de idiomas y marcos (como Java y Maven, Node y WebDriver.io, o cualquier otro marco y tecnología creados en Selenium). Además, un proyecto de pruebas de interfaz de usuario se puede generar fácilmente mediante el uso de el tipo de archivo del proyecto de AEM.
Las pruebas de interfaz de usuario se ejecutan como parte de una puerta de calidad específica para cada canalización de Cloud Manager con un dedicated Pruebas de IU personalizadas paso a paso. Cualquier prueba de la interfaz de usuario, incluidas la regresión y las nuevas funcionalidades, permite detectar y notificar errores.
A diferencia de las pruebas funcionales personalizadas, que son pruebas HTTP escritas en Java, las pruebas de interfaz de usuario pueden ser una imagen de Docker con pruebas escritas en cualquier idioma, siempre y cuando sigan las convenciones definidas en la sección Creación de pruebas de IU.
Adobe recomienda seguir la estructura y el idioma (JavaScript y WDIO) proporcionados en la variable AEM tipo de archivo del proyecto.
Para que Cloud Manager pueda crear y ejecutar sus pruebas de interfaz de usuario, debe incluirse en esta función añadiendo un archivo al repositorio.
testing.properties
.ui-tests.version=1
.pom.xml
archivo del submódulo Pruebas de interfaz de usuario .tar.gz
archivo.Las pruebas de interfaz de usuario se crean y las ejecuciones se omiten si este archivo no está presente.
Para incluir un testing.properties
en el artefacto de compilación, agregue un include
en la assembly-ui-test-docker-context.xml
archivo.
[...]
<includes>
<include>Dockerfile</include>
<include>wait-for-grid.sh</include>
<include>testing.properties</include> <!- opt-in test module in Cloud Manager -->
</includes>
[...]
Si el proyecto no incluye esta línea, deberá editar el archivo para optar por la prueba de IU.
El archivo puede contener una línea que aconseja no editarlo. Esto se debe a que se introdujo en el proyecto antes de que se introdujera la prueba de IU de inclusión y a que los clientes no tenían la intención de editar el archivo. Esto se puede ignorar con seguridad.
Un proyecto de Maven genera un contexto de compilación de Docker. Este contexto de compilación de Docker describe cómo crear una imagen de Docker que contenga las pruebas de interfaz de usuario, que los usuarios de Cloud Manager generarán una imagen de Docker que contenga las pruebas de IU reales.
En esta sección se describen los pasos necesarios para agregar un proyecto de pruebas de interfaz de usuario al repositorio.
La variable Tipo de archivo del proyecto AEM puede generar un proyecto de pruebas de IU porque no tiene requisitos especiales para el lenguaje de programación.
Para generar un contexto de compilación de Docker, necesita un módulo Maven que:
Dockerfile
y todos los demás archivos necesarios para crear la imagen Docker con sus pruebas.ui-test-docker-context
clasificador.La forma más sencilla de hacerlo es configurar la variable Complemento Ensamblado de Maven para crear el archivo de contexto de compilación de Docker y asignarle el clasificador adecuado.
Puede crear pruebas de interfaz de usuario con diferentes tecnologías y marcos, pero en esta sección se da por hecho que el diseño del proyecto es similar al siguiente.
├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│ ├── package.json
│ ├── index.js
│ └── wdio.conf.js
└── wait-for-grid.sh
La variable pom.xml
se encarga de la compilación de Maven. Añada una ejecución al complemento Maven Assembly similar a la siguiente.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>${project.basedir}/assembly-ui-test-docker-context.xml</descriptor>
</descriptors>
<tarLongFileMode>gnu</tarLongFileMode>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
Esta ejecución ordena al complemento Maven Assembly que cree un archivo basado en las instrucciones contenidas en assembly-ui-test-docker-context.xml
, se denomina descriptor de ensamblado en la jerga del complemento. El descriptor de ensamblado enumera todos los archivos que deben formar parte del archivo.
<assembly>
<id>ui-test-docker-context</id>
<includeBaseDirectory>false</includeBaseDirectory>
<formats>
<format>tar.gz</format>
</formats>
<fileSets>
<fileSet>
<directory>${basedir}</directory>
<includes>
<include>Dockerfile</include>
<include>wait-for-grid.sh</include>
</includes>
</fileSet>
<fileSet>
<directory>${basedir}/test-module</directory>
<excludes>
<exclude>node/**</exclude>
<exclude>node_modules/**</exclude>
<exclude>reports/**</exclude>
</excludes>
</fileSet>
</fileSets>
</assembly>
El descriptor de ensamblado indica al complemento que cree un archivo de tipo .tar.gz
y asigna la variable ui-test-docker-context
clasificador para él. Además, enumera los archivos que deben incluirse en el archivo, incluyendo los siguientes.
Dockerfile
, obligatorio para crear la imagen Dockerwait-for-grid.sh
secuencia de comandos, cuyos propósitos se describen a continuacióntest-module
carpetaEl descriptor de ensamblado también excluye algunos archivos que podrían generarse al ejecutar las pruebas de IU localmente. Esto garantiza un archivo más pequeño y compilaciones más rápidas.
El archivo que contiene el contexto de compilación de Docker se recoge automáticamente en Cloud Manager, que creará la imagen de Docker que contiene las pruebas durante sus canalizaciones de implementación. Al final, Cloud Manager ejecutará la imagen de Docker para ejecutar las pruebas de interfaz de usuario con la aplicación.
La compilación debe producir cero o un archivo. Si no genera archivos, el paso de prueba pasa de forma predeterminada. Si la compilación produce más de un archivo, qué archivo se selecciona no es determinista.
En esta sección se describen las convenciones que debe seguir la imagen de Docker que contiene las pruebas de IU. La imagen Docker se crea a partir del contexto de compilación de Docker descrito en la sección anterior.
Las siguientes variables de entorno se pasarán a la imagen de Docker en tiempo de ejecución.
Variable | Ejemplos | Descripción |
---|---|---|
SELENIUM_BASE_URL |
http://my-ip:4444 |
La URL del servidor de Selenium |
SELENIUM_BROWSER |
chrome |
Implementación del explorador utilizada por el servidor de Selenium |
AEM_AUTHOR_URL |
http://my-ip:4502/context-path |
Dirección URL de la instancia de autor de AEM |
AEM_AUTHOR_USERNAME |
admin |
El nombre de usuario para iniciar sesión en la instancia de autor de AEM |
AEM_AUTHOR_PASSWORD |
admin |
La contraseña para iniciar sesión en la instancia de autor de AEM |
AEM_PUBLISH_URL |
http://my-ip:4503/context-path |
La URL de la instancia de publicación de AEM |
AEM_PUBLISH_USERNAME |
admin |
El nombre de usuario para iniciar sesión en la instancia de publicación de AEM |
AEM_PUBLISH_PASSWORD |
admin |
La contraseña para iniciar sesión en la instancia de publicación de AEM |
REPORTS_PATH |
/usr/src/app/reports |
La ruta en la que se debe guardar el informe XML de los resultados de la prueba |
UPLOAD_URL |
http://upload-host:9090/upload |
La URL donde debe cargarse el archivo a para que sea accesible para Selenium |
Antes de que comiencen las pruebas, es responsabilidad de la imagen Docker asegurarse de que el servidor Selenium esté funcionando. Esperar el servicio de Selenium es un proceso de dos pasos.
SELENIUM_BASE_URL
variable de entorno.Una vez que el extremo de estado de Selenium responde con una respuesta positiva, las pruebas pueden comenzar.
La imagen Docker debe generar informes de prueba en formato XML JUnit y guardarlos en la ruta especificada por la variable de entorno REPORTS_PATH
. El formato JUnit XML es un formato ampliamente utilizado para informar sobre los resultados de las pruebas. Si la imagen Docker utiliza Java y Maven, los módulos de prueba estándar como Complemento Maven Surefire y Complemento Maven FailedSafe puede generar estos informes de forma predeterminada.
Si la imagen Docker está implementada con otros lenguajes de programación o ejecutores de prueba, compruebe la documentación de las herramientas seleccionadas para generar informes XML de JUnit.
Las pruebas a veces deben cargar archivos en la aplicación que se está probando. Para que la implementación de Selenium sea flexible con respecto a sus pruebas, no es posible cargar directamente un recurso a Selenium. En su lugar, la carga de un archivo requiere los siguientes pasos.
UPLOAD_URL
variable de entorno.
curl -X POST ${UPLOAD_URL} -F "data=@file.txt"
.200 OK
respuesta del tipo text/plain
.
<input>
para probar las cargas de archivos en la aplicación.