Pruebas de IU ui-testing
La prueba de IU personalizada es una característica opcional que le permite crear y ejecutar automáticamente pruebas de IU para sus aplicaciones.
Información general custom-ui-testing
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 pruebas de TI ya admiten la creación y automatización de pruebas personalizadas mediante las API de AEM.
Las pruebas de IU se empaquetan en una imagen Docker para permitir una amplia variedad de lenguajes y marcos de trabajo (como Cypress, Selenium, Java y Maven, y JavaScript). Además, se puede generar fácilmente un proyecto de pruebas de interfaz de usuario utilizando el arquetipo del proyecto de AEM.
El Adobe fomenta el uso de Cypress, ya que ofrece recarga en tiempo real y espera automática, lo que ayuda a ahorrar tiempo y mejora la productividad durante las pruebas. Cypress también proporciona una sintaxis sencilla e intuitiva, lo que facilita el aprendizaje y el uso, incluso para usuarios que son nuevos en las pruebas.
Las pruebas de interfaz de usuario se ejecutan como una puerta de calidad en el paso Pruebas de IU personalizadas, necesario en canalizaciones de producción, opcional en canalizaciones que no sean de producción. Cualquier prueba de la IU, 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 Docker. Las pruebas se pueden escribir en cualquier idioma, siempre y cuando sigan las convenciones definidas en la sección Pruebas de generación de interfaz de usuario.
Introducción a las pruebas de IU get-started-ui-tests
En esta sección se describen los pasos necesarios para configurar las pruebas de IU para la ejecución en Cloud Manager.
-
Decida el marco de trabajo de prueba que desee utilizar.
-
Para Cypress (predeterminado), usa el código de muestra del repositorio de muestras de prueba de AEM o usa el código de muestra que se genera automáticamente en la carpeta
ui.testsde tu repositorio de Cloud Manager. -
Para Playwright, usa el código de muestra del repositorio de muestras de prueba de AEM.
-
Para Webdriver.IO, use el código de ejemplo del repositorio de muestras de prueba de AEM.
-
Para Selenium WebDriver, use el código de ejemplo del repositorio de muestras de prueba de AEM.
-
Para otros lenguajes de programación, consulte la sección Generación de pruebas de IU en este documento para configurar el proyecto de prueba.
-
-
Asegúrese de que las pruebas de IU estén activadas según la sección Inclusión del cliente de este documento.
-
Desarrolle sus casos de prueba y ejecute las pruebas localmente.
-
Confirme su código en el repositorio de Cloud Manager y ejecute una canalización de Cloud Manager.
Generar pruebas de interfaz de usuario building-ui-tests
Un proyecto de Maven genera un contexto de generación de Docker. Este contexto de generación de Docker describe cómo crear una imagen de Docker que contenga las pruebas de IU, que Cloud Manager usa para generar 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.
Generar un contexto de generación de Docker generate-docker-build-context
Para generar un contexto de generación de Docker, necesita un módulo de Maven que:
- Produzca un archivo que contenga un
Dockerfiley todos los demás archivos necesarios para generar la imagen Docker con sus pruebas. - Etiqueta el archivo con el clasificador
ui-test-docker-context.
La forma más sencilla es configurar el Complemento de Maven Assembly para crear el archivo de contexto de generación de Docker y asignarle el clasificador adecuado.
Puede crear pruebas de interfaz de usuario con diferentes tecnologías y marcos de trabajo, 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
El archivo pom.xml se encarga de la generación de Maven. Agregue una ejecución al complemento de 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 de 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 el clasificador ui-test-docker-context para él. Además, enumera los archivos que deben incluirse en el archivo, incluidos los siguientes:
- Un
Dockerfile, obligatorio para crear la imagen Docker - El script
wait-for-grid.sh, cuyos propósitos se describen a continuación - Las pruebas de interfaz de usuario reales, implementadas por un proyecto Node.js en la carpeta
test-module
El 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 generaciones más rápidas.
Cloud Manager recoge automáticamente el archivo de contexto de compilación de Docker y crea la imagen de prueba durante las canalizaciones de implementación. Finalmente, Cloud Manager ejecuta la imagen Docker para ejecutar las pruebas de interfaz de usuario contra la aplicación.
La generación debe producir ningún o un archivo. Si no genera ningún archivo, el paso de prueba se aprobará de forma predeterminada. Si la generación produce más de un archivo, qué archivo se seleccione no es determinista.
Inclusión del cliente customer-opt-in
Para que Cloud Manager pueda generar y ejecutar sus pruebas de IU, debe incluirse en esta funcionalidad al agregar un archivo al repositorio.
- El nombre del archivo debe ser
testing.properties. - El contenido del archivo debe ser
ui-tests.version=1. - El archivo debe estar en el módulo secundario de Maven para pruebas de IU junto al archivo
pom.xmldel módulo secundario de pruebas de IU. - El archivo debe estar en la raíz del archivo de generación
tar.gz.
La generación de pruebas de interfaz de usuario y las ejecuciones se omite si este archivo no está presente.
Para incluir un archivo testing.properties en el artefacto de generación, agregue un enunciado include en el 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 está utilizando las muestras proporcionadas por Adobe:
-
Para la carpeta basada en JavaScript
ui.testsgenerada a partir del Arquetipo de proyecto de AEM, puede ejecutar el siguiente comando y añadir la configuración necesaria.code language-shell echo "ui-tests.version=1" > testing.properties if ! grep -q "testing.properties" "assembly-ui-test-docker-context.xml"; then awk -v line=' <include>testing.properties</include>' '/<include>wait-for-grid.sh<\/include>/ { printf "%s\n%s\n", $0, line; next }; 1' assembly-ui-test-docker-context.xml > assembly-ui-test-docker-context.xml.new && mv assembly-ui-test-docker-context.xml.new assembly-ui-test-docker-context.xml fi -
Los ejemplos de prueba de Cypress y Java Selenium proporcionados por Adobe ya tienen el indicador de inclusión establecido.
Escribir pruebas de interfaz de usuario writing-ui-tests
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 generación de Docker descrito en la sección anterior.
Variables de entorno environment-variables
Las siguientes variables de entorno se pasan a la imagen de Docker en tiempo de ejecución, en función del marco de trabajo.
SELENIUM_BASE_URLhttp://my-ip:4444SELENIUM_BROWSERchromeAEM_AUTHOR_URLhttp://my-ip:4502/context-pathAEM_AUTHOR_USERNAMEadminAEM_AUTHOR_PASSWORDadminAEM_PUBLISH_URLhttp://my-ip:4503/context-pathAEM_PUBLISH_USERNAMEadminAEM_PUBLISH_PASSWORDadminREPORTS_PATH/usr/src/app/reportsUPLOAD_URLhttp://upload-host:9090/uploadPROXY_HOSTproxy-hostPROXY_HTTPS_PORT8071PROXY_HTTP_PORT8070PROXY_CA_PATH/path/to/root_ca.pemPROXY_OBSERVABILITY_PORT8081healthcheck del servidor proxyPROXY_RETRY_ATTEMPTS12PROXY_RETRY_DELAY5* these values will be empty if there is no publish instance
Las muestras de prueba de Adobe proporcionan funciones de ayuda para acceder a los parámetros de configuración:
Cypress: utilizar la función estándar Cypress.env('VARIABLE_NAME')
Generar informes de prueba generate-test-reports
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 la creación de informes sobre los resultados de las pruebas. Si la imagen Docker utiliza Java y Maven, los módulos de prueba estándar como el complemento de Maven Surefire y el complemento de Maven Failesafe pueden 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.
request.log.Requisitos previos prerequisites
- Las pruebas en Cloud Manager se ejecutan con un usuario administrador técnico.
- La infraestructura contenerizada que se contempla para las pruebas funcionales está limitada por los siguientes límites:
Detalles específicos de Selenium
Esperando a que Selenium esté listo waiting-for-selenium
Antes de que comiencen las pruebas, es responsabilidad de la imagen Docker asegurarse de que el servidor Selenium funcione. Esperar por el servicio de Selenium es un proceso de dos pasos.
- Lea la URL del servicio de Selenium desde la
SELENIUM_BASE_URLvariable de entorno. - Encuesta a intervalos regulares al extremo de estado expuesto por la API de Selenium.
Una vez que el extremo de estado de Selenium dé una respuesta positiva, las pruebas podrán comenzar.
Las muestras de prueba de IU de Adobe utilizan wait-for-grid.sh. Se ejecuta al inicio de Docker y ejecuta pruebas solo después de que la cuadrícula esté lista.
Captura de pantallas y vídeos capture-screenshots
La imagen del Docker puede generar resultados de prueba adicionales (por ejemplo, capturas de pantalla o vídeos) y guardarlos en la ruta especificada por la variable de entorno REPORTS_PATH. Cualquier archivo que se encuentre debajo de REPORTS_PATH se incluirá en el archivo de resultados de la prueba.
Las muestras de prueba proporcionadas por Adobe de forma predeterminada crean capturas de pantalla para cualquier prueba fallida.
Puede utilizar las funciones de ayuda para crear capturas de pantalla a través de las pruebas.
Si se crea un archivo de resultados de prueba durante la ejecución de una prueba de IU, puede descargarlo desde Cloud Manager si hace clic en el botón Download Details en el paso Pruebas de IU personalizadas.
Cargar archivos upload-files
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 un recurso directamente en Selenium. En su lugar, la carga de un archivo requiere los siguientes pasos.
-
Cargue el archivo en la dirección URL especificada por la
UPLOAD_URLvariable de entorno.- La carga debe realizarse en una solicitud de POST con un formulario de varias partes.
- El formulario de varias partes debe tener un único campo de archivo.
- Equivalente a
curl -X POST ${UPLOAD_URL} -F "data=@file.txt". - Consulte la documentación y las bibliotecas del lenguaje de programación utilizado en la imagen Docker para saber cómo realizar una solicitud HTTP de este tipo.
-
Si la carga se realiza correctamente, la solicitud devolverá una
200 OKrespuesta del tipotext/plain.- El contenido de la respuesta es un controlador de archivo opaco.
- Puede utilizar este identificador en lugar de una ruta de archivo en un elemento
<input>para probar la carga de archivos en la aplicación.
Detalles específicos de Cypress
Configuración del proxy HTTP
El punto de entrada del contenedor Docker debe comprobar el valor de la variable de entorno PROXY_HOST.
Si este valor está vacío, no se requieren pasos adicionales y las pruebas deben ejecutarse sin utilizar un proxy HTTP.
Si no está vacío, el script de punto de entrada debe hacer lo siguiente:
-
Configure una conexión proxy HTTP para ejecutar pruebas de interfaz de usuario exportando la variable de entorno
HTTP_PROXYcreada con los siguientes valores:- Host de proxy proporcionado por la variable
PROXY_HOST - Puerto del proxy proporcionado por la variable
PROXY_HTTPS_PORToPROXY_HTTP_PORT(se utiliza la variable con un valor que no está vacío)
- Host de proxy proporcionado por la variable
-
Establezca el certificado de CA que se utiliza al conectarse al proxy HTTP. Su ubicación la proporciona la variable
PROXY_CA_PATH.- Exportar
NODE_EXTRA_CA_CERTSvariable de entorno.
- Exportar
-
Espere hasta que el proxy HTTP esté listo.
- Para comprobar la preparación, se pueden utilizar las variables de entorno
PROXY_HOST,PROXY_OBSERVABILITY_PORT,PROXY_RETRY_ATTEMPTSyPROXY_RETRY_DELAY. - Puede comprobarlo usando una solicitud cURL, asegurándose de instalar cURL en su
Dockerfile.
- Para comprobar la preparación, se pueden utilizar las variables de entorno
Se puede encontrar una implementación de ejemplo en el punto de entrada del módulo de prueba de muestra de Cypress en GitHub.
Detalles específicos del dramaturgo
Playwright es la infraestructura de prueba elegida.Configuración del proxy HTTP
De forma similar a Cypress, las pruebas deben utilizar el proxy HTTP si se proporciona una variable de entorno PROXY_HOST que no esté vacía.
En tal caso, es necesario realizar las siguientes ediciones.
Dockerfile
Instale cURL y libnss3-tools, que proporciona certutil.
RUN apt -y update \
&& apt -y --no-install-recommends install curl libnss3-tools \
&& rm -rf /var/lib/apt/lists/*
Script Entrypoint
Incluya un script bash que, en caso de que se proporcione la variable de entorno PROXY_HOST, haga lo siguiente:
- Exportar variables relacionadas con proxy como
HTTP_PROXYyNODE_EXTRA_CA_CERTS - Use
certutilpara instalar el certificado de CA proxy para Chromium™. - Espere hasta que el proxy HTTP esté listo (o salga si hay algún error).
Ejemplo de implementación:
# setup proxy environment variables and CA certificate
if [ -n "${PROXY_HOST:-}" ]; then
if [ -n "${PROXY_HTTPS_PORT:-}" ]; then
export HTTP_PROXY="https://${PROXY_HOST}:${PROXY_HTTPS_PORT}"
elif [ -n "${PROXY_HTTP_PORT:-}" ]; then
export HTTP_PROXY="http://${PROXY_HOST}:${PROXY_HTTP_PORT}"
fi
if [ -n "${PROXY_CA_PATH:-}" ]; then
echo "installing certificate"
mkdir -p $HOME/.pki/nssdb
certutil -d sql:$HOME/.pki/nssdb -A -t "CT,c,c" -n "EaaS Client Proxy Root" -i $PROXY_CA_PATH
export NODE_EXTRA_CA_CERTS=${PROXY_CA_PATH}
fi
if [ -n "${PROXY_OBSERVABILITY_PORT:-}" ] && [ -n "${HTTP_PROXY:-}" ]; then
echo "waiting for proxy"
curl --silent --retry ${PROXY_RETRY_ATTEMPTS:-3} --retry-connrefused --retry-delay ${PROXY_RETRY_DELAY:-10} \
--proxy ${HTTP_PROXY} --proxy-cacert ${PROXY_CA_PATH:-""} \
${PROXY_HOST}:${PROXY_OBSERVABILITY_PORT}
if [ $? -ne 0 ]; then
echo "proxy is not ready"
exit 1
fi
fi
fi
Configuración del dramaturgo
Modifique la configuración del dramaturgo (por ejemplo, en playwright.config.js) para utilizar un proxy en caso de que se establezca la variable de entorno HTTP_PROXY.
Ejemplo de implementación:
const proxyServer = process.env.HTTP_PROXY || ''
// enable proxy if set
if (proxyServer !== '') {
cfg.use.proxy = {
server: proxyServer,
}
}
Ejecución de pruebas de IU locales run-ui-tests-locally
Antes de activar las pruebas de IU en una canalización de Cloud Manager, Adobe recomienda ejecutar las pruebas de IU localmente en AEM as a Cloud Service SDK. O bien, ejecútelo con una instancia real de AEM as a Cloud Service.
Ejemplo de prueba de Cypress cypress-sample
-
Abra un elemento shell y vaya a la carpeta
ui.tests/test-modulede su repositorio -
Instalar Cypress y otros requisitos previos
code language-shell npm install -
Establecer las variables de entorno necesarias para la ejecución de pruebas
code language-shell export AEM_AUTHOR_URL=https://author-<program-id>-<environment-id>.adobeaemcloud.com export AEM_AUTHOR_USERNAME=<user> export AEM_AUTHOR_PASSWORD=<password> export AEM_PUBLISH_URL=https://publish-<program-id>-<environment-id>.adobeaemcloud.com export AEM_PUBLISH_USERNAME=<user> export AEM_PUBLISH_PASSWORD=<password> export REPORTS_PATH=target/ -
Ejecute las pruebas con uno de los siguientes comandos
code language-shell npm test # Using default Cypress browser npm run test-chrome # Using Google Chrome browser npm run test-firefox # Using Firefox browser
target/ del repositorio.Muestra de prueba de WebdriverIO de JavaScript javascript-sample
-
Abra un shell y vaya a la carpeta
ui.testsen el repositorio. -
Ejecute el siguiente comando para iniciar las pruebas con Maven.
code language-shell mvn verify -Pui-tests-local-execution \ -DAEM_AUTHOR_URL=https://author-<program-id>-<environment-id>.adobeaemcloud.com \ -DAEM_AUTHOR_USERNAME=<user> \ -DAEM_AUTHOR_PASSWORD=<password> \ -DAEM_PUBLISH_URL=https://publish-<program-id>-<environment-id>.adobeaemcloud.com \ -DAEM_PUBLISH_USERNAME=<user> \ -DAEM_PUBLISH_PASSWORD=<password>
- Este comando inicia una instancia independiente de Selenium y ejecuta las pruebas correspondientes.
- Los archivos de registro se almacenan en la carpeta
target/reportsde su repositorio - Debe asegurarse de que tiene la última versión de Chrome, ya que la prueba descarga la última versión de ChromeDriver automáticamente para realizar pruebas.
Muestra de prueba de Playwright playwright-sample
-
Abra un elemento shell y vaya a la carpeta
ui.testsde su repositorio -
Ejecute el siguiente comando para crear una imagen de docker con Maven
code language-shell mvn clean package -Pui-tests-docker-build -
Ejecute el siguiente comando para iniciar las pruebas con Maven
code language-shell mvn verify -Pui-tests-docker-execution \ -DAEM_AUTHOR_URL=https://author-<program-id>-<environment-id>.adobeaemcloud.com \ -DAEM_AUTHOR_USERNAME=<user> \ -DAEM_AUTHOR_PASSWORD=<password> \ -DAEM_PUBLISH_URL=https://publish-<program-id>-<environment-id>.adobeaemcloud.com \ -DAEM_PUBLISH_USERNAME=<user> \ -DAEM_PUBLISH_PASSWORD=<password>
target/ del repositorio.Ejemplo de prueba de Java Selenium WebDriver java-sample
-
Abra un elemento shell y vaya a la carpeta
ui.tests/test-modulede su repositorio -
Ejecute el siguiente comando para iniciar las pruebas con Maven
code language-shell # Start selenium docker image # we mount /tmp/shared as a shared volume that will be used between selenium and the test module for uploads docker run -d -p 4444:4444 -v /tmp/shared:/tmp/shared selenium/standalone-chromium:latest # Run the tests using the previously started Selenium instance mvn verify -Pui-tests-local-execution -DSELENIUM_BASE_URL=http://<server>:4444
target/reports del repositorio.