Ejecute pruebas de extremo a extremo con el modelo de automatización de pruebas de interfaz de usuario (UTAM) ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Probar aplicaciones es fundamental para garantizar la calidad y existen diferentes tipos de pruebas, como pruebas unitarias, pruebas de integración y pruebas de extremo a extremo. En esta publicación, nos centraremos en las pruebas automatizadas de extremo a extremo (E2E) y presentaremos el Modelo de automatización de pruebas de interfaz de usuario (UTAM) . UTAM es una solución de código abierto creada por Salesforce que le permite ejecutar pruebas E2E en cualquier tipo de aplicación. Lo guiaremos a través de un ejemplo práctico con E-Bikes , una de nuestras aplicaciones de muestra.

Una breve introducción a las pruebas de extremo a extremo

Las pruebas E2E a menudo se realizan con una herramienta de prueba de interfaz de usuario automatizada, como WebdriverIO o Selenium . A diferencia de las pruebas unitarias, que cubren componentes individuales de forma aislada, las pruebas E2E imitan de cerca las interacciones de los usuarios comerciales. Las pruebas E2E utilizan un navegador real para interactuar con los componentes y navegar por las pantallas al ejecutar escenarios de prueba.

Una ventaja clave de las pruebas E2E es que le permiten probar una aplicación incluso si no tiene acceso completo a su código fuente. Imaginemos que desea probar una aplicación de Salesforce que se integra con un paquete de AppExchange. No tiene acceso a las fuentes de Lightning Experience o del paquete. Sin embargo, aún puede probar la aplicación con pruebas E2E.

Sin embargo, este poder tiene un costo. Un inconveniente importante de las pruebas E2E es que se sabe que son frágiles y difíciles de mantener. Cada vez que una aplicación web cambia, también lo hace el DOM. Estos cambios tienden a romper las pruebas E2E porque están estrechamente relacionados con el DOM. En el contexto de nuestro ejemplo anterior, una actualización de Lightning Experience, como una nueva versión de Salesforce o una nueva versión del paquete, podría interrumpir sus pruebas.

Este costo de mantenimiento es la razón por la que generalmente es preferible invertir en pruebas unitarias como prioridad, luego pruebas de integración y, finalmente, pruebas E2E. Hay una regla de oro en el desarrollo de software que lo resume bien:

Cuanto más cerca esté del código fuente, más barato será encontrar y corregir errores.

Con estos pros y contras en mente, un equipo de Salesforce ideó una propuesta revolucionaria: el modelo de automatización de pruebas de interfaz de usuario (UI Test Automation Model, UTAM).

Sobre la UTAM

UTAM aborda las limitaciones de las pruebas E2E convencionales haciéndolas más fáciles de escribir y mantener. UTAM no reemplaza una herramienta de prueba de UI, pero la complementa al desacoplar el código de prueba del DOM gracias a los objetos de página.

Usted escribe objetos de página UTAM en JSON con una gramática poderosa y fácil de entender. Los objetos de página son bloques reutilizables que le permiten hacer referencia al DOM de la página bajo prueba con selectores de CSS. Puede componer objetos de página para crear patrones avanzados.

El hecho de que los objetos de página actúen como un contrato compartible y estén escritos en JSON son los principales diferenciadores en comparación con otras herramientas de prueba de IU. Esto permite que UTAM trabaje con un enfoque mayoritariamente independiente del idioma. En otras palabras, varios equipos pueden colaborar y compartir objetos de página independientemente de la tecnología que utilicen para las pruebas.

Cuando esté listo para ejecutar pruebas E2E, UTAM compila los objetos de su página en JavaScript, TypeScript o Java, según la configuración de su proyecto. Sus pruebas pueden entonces aprovechar los objetos de página compilados para interactuar con su página.

Ejecución de pruebas de extremo a extremo con UTAM

Ahora que hemos cubierto lo que es y lo que hace la UTAM, veamos algunos ejemplos prácticos. Comenzaremos con un pequeño "Hola, mundo" y le mostraremos cómo probar una aplicación real: la aplicación de ejemplo E-Bikes.

Probar un ejemplo de "Hola, mundo"

Comencemos con algo simple: un ejemplo de “Hola mundo” tomado de los excelentes tutoriales de la UTAM . En este ejemplo, estamos probando una página HTML estática que muestra "¡Hola, 🌍 🌏 🌎 !"

Estos son los pasos clave necesarios para probar esta página:

1. Declaramos un objeto de página JSON que contiene un elemento world . Este elemento tiene un selector de clase CSS .world , que coincide con un elemento DOM en la página bajo prueba.
2. Compilamos nuestro objeto de página, que genera una clase con un método getWorld que está vinculado al elemento world que hemos definido en JSON.
3. Usamos el método getWorld del objeto de página compilado en nuestro código de prueba para acceder al contenido del DOM con la clase .world CSS.

Si bien esto puede parecer detallado para un caso de uso tan simple, el poder de UTAM se vuelve obvio cuando las páginas son más complejas. En esos casos (que están más cerca de las aplicaciones de la vida real), la composición y la reutilización son imprescindibles, y UTAM está aquí para ayudar.

Prueba de la aplicación de muestra E-Bikes

UTAM no se limita a probar aplicaciones de Salesforce; funciona con cualquier tecnología o plataforma. Pero Salesforce proporciona un conjunto de cientos de objetos de página UTAM reutilizables para los componentes básicos de Lightning (entrada de relámpago, botón de relámpago, etc.) y Lightning Experience (consulte los enlaces en la sección de recursos). Este es un gran ahorro de tiempo al escribir pruebas E2E para aplicaciones de Salesforce. Esta es la razón por la que varios equipos de ingeniería de Salesforce utilizan UTAM internamente para probar sus aplicaciones.

Veamos cómo ejecutamos pruebas integrales en la página de la aplicación Product Explorer Lightning de la aplicación de muestra E-Bikes .

Esta página contiene varios componentes web Lightning estándar y personalizados. Acceder a los elementos de esos componentes explorando el DOM de la página sería un verdadero desafío sin los objetos de la página base de UTAM porque tendríamos que atravesar varias capas de Shadow DOM .

Aquí hay un diagrama que ayuda a poner esto en perspectiva. Presenta una vista simplificada de los componentes anidados que componen esta página. Los componentes personalizados se representan en naranja y los componentes base Lightning en azul.

Los componentes personalizados se someten a pruebas unitarias, pero nuestro objetivo es ejecutar también pruebas E2E para verificar las interacciones de los usuarios. Este es el escenario que estamos probando con la UTAM:

1. Verifique la información de paginación predeterminada en la lista de mosaicos de productos
2. Comprobar que la ficha del producto seleccionado está vacía por defecto
3. Introduzca un término de búsqueda en los filtros de productos
4. Consulta la información de paginación actualizada
5. Seleccione el mosaico del primer producto
6. Compruebe que la selección se muestra en la ficha del producto
7. Haga clic en el icono del botón de la tarjeta del producto para abrir la página de registro del producto
8. Asegúrese de que la página de registro del producto esté abierta

Antes de escribir el código para la prueba E2E, la mayor parte del esfuerzo se dedica a la definición de los objetos de la página JSON de UTAM para los componentes personalizados que forman parte de la prueba. En aras de la brevedad, no cubriremos todas sus definiciones aquí, pero puede echar un vistazo al repositorio E-Bikes GitHub . En la carpeta que contiene los metadatos de Lightning Web Components, encontrará subcarpetas __utam__ con los objetos de página JSON.

Por ejemplo, así es como se ve el objeto de la página de filtro de productos y cómo recuperamos la entrada de búsqueda gracias a un objeto de página base de entrada Lightning y un selector de clase CSS .search :

 { "sombra": { "elementos": [ { "nombre": "entrada de búsqueda", "selector": { "css": ".buscar" }, "tipo": "utam-lightning/pageObjects/input", "público": cierto } ] }
}

Gracias a los objetos de la página UTAM, el escenario de prueba E2E anterior se reduce a menos de 100 líneas de JavaScript , incluida la configuración de la prueba (no se muestra aquí):

 it('muestra, filtra y selecciona productos de la lista', async () => { // Comprobar la información de paginación predeterminada en la lista de mosaicos de productos let pageInfo = esperar productTileList.getPaginationInfo(); expect(pageInfo).toBe(PAGINATION_ALL_ITEMS); // Verifique la selección vacía predeterminada en la tarjeta del producto const productCardBodyText = await productCard.getBodyText(); expect(productCardBodyText).toBe(SELECTION_EMPTY); // Ingrese el término de búsqueda const searchInput = esperar productFilter.getSearchInput(); aguardar searchInput.setText('fuse'); // Espere la información de paginación actualizada espera productTileList.waitForPaginationUpdate(PAGINATION_FILTERED_ITEMS); // Comprobar la información de paginación actualizada pageInfo = espera productTileList.getPaginationInfo(); expect(pageInfo).toBe(PAGINATION_FILTERED_ITEMS); // Seleccione el mosaico del primer producto const productTiles = await productTileList.getTiles(); espera productTiles[0].click(); // Esperar a la selección del producto espera productCard.waitForSelectionUpdate('FUSE X1'); // Abrir registro de producto seleccionado espera productCard.clickOpenRecord(); // Asegurarse de que la página de registro del producto esté abierta esperar domDocument.waitFor(async () => RECORD_PAGE_URL.test(esperar domDocument.getUrl()) );
});

Gracias a UTAM, este código de prueba es bastante fácil de leer (no está abarrotado de código repetitivo o referencias CSS), y probablemente será estable porque no necesitará actualizarse cuando cambie el DOM (cuando se elimine una clase CSS o renombrado, por ejemplo). La mayor parte del esfuerzo de mantenimiento se centrará en los objetos de la página JSON.

palabras de cierre

Acabamos de arañar la superficie de lo que puede hacer la UTAM. Vimos un repaso sobre qué son las pruebas E2E, qué es UTAM y cómo aporta valor agregado al desacoplar el código de prueba del DOM. Finalmente, exploramos un par de ejemplos de pruebas E2E con UTAM. Dirígete al sitio web de la UTAM y echa un vistazo a la guía y los excelentes tutoriales para aprender conceptos más avanzados, como selectores dinámicos o composición con métodos, solo por mencionar algunos.

Recursos

• El sitio web de la UTAM para documentación y tutoriales
• Recetas UTAM para un repositorio lleno de ejemplos:
• Objetos de página UTAM para componentes base Lightning:
• Repositorio de aplicaciones de muestra de E-Bikes para un ejemplo de pruebas de extremo a extremo con UTAM

Sobre el Autor

Philippe Ozil es un defensor principal de desarrolladores en Salesforce, donde se enfoca en la plataforma de Salesforce. Escribe contenido técnico y habla con frecuencia en conferencias. Es un desarrollador de pila completa y disfruta trabajar en proyectos DevOps, robótica y realidad virtual. Sígalo en Twitter @PhilippeOzil o consulte sus proyectos de GitHub @pozil .

…

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam.html