Pruebas de extremo a extremo de aplicaciones Electron: más allá del soporte de Electron de Playwright

Esta guía es para los desarrolladores y el equipo de QA de una aplicación de escritorio Electron.Explica qué hace que una aplicación así se pruebe de otra manera, describe con imparcialidad la API de Electron de Playwright, y después muestra una prueba de extremo a extremo que recorre la página, el diálogo de archivos nativo, una exportación y su notificación, ejecutada en cada compilación.

Qué hace que una aplicación Electron se pruebe de otra manera

Una aplicación Electron son dos programas que trabajan juntos.El proceso principal se ejecuta en Node.js: abre las ventanas, controla el ciclo de vida de la aplicación y pide al sistema operativo todo lo nativo, como los menús, los diálogos y los iconos de la bandeja.Cada ventana ejecuta después un proceso de renderizado, que es una página de Chromium: HTML, CSS y JavaScript, como un sitio web.

Para las pruebas, esta división importa.Una herramienta hecha para sitios web ve la página y solo la página.Un usuario ve el conjunto: la barra de menús, el diálogo de archivos de Windows que se abre con Abrir, el aviso que dice que la exportación ha terminado, el icono que sigue en la bandeja después de cerrar la ventana.

Lo que cubre la API de Electron de Playwright, y dónde se detiene

Entre las herramientas de pruebas de interfaz para Electron, Playwright es la que la mayoría de los equipos prueba primero, porque ya la usan para su aplicación web.Su clase Electron está documentada como soporte experimental, para Electron 21 y versiones posteriores.La prueba inicia la aplicación desde su script de entrada, obtiene cada ventana como una página de Playwright, y ejecuta código en el proceso principal con evaluate().

Es un acceso real a la aplicación.Cada localizador, clic y aserción que ofrece Playwright en una página web funciona en el proceso de renderizado, una segunda ventana llega a través del evento window, y evaluate() puede leer o cambiar el estado de la aplicación.Consulte la clase ElectronApplication para ver la lista completa.

El límite está igual de claramente documentado.Las llamadas a diálogos nativos como dialog.showOpenDialog no se interceptan, porque van directamente al sistema operativo, y la documentación aconseja sustituir esos métodos desde la prueba por un stub que devuelva la ruta de archivo que se quiera.El diálogo real nunca se abre, así que nunca se prueba.Lo mismo vale para todo lo demás que el sistema operativo dibuja fuera de la página.

Datos consultados en la documentación de Playwright el 6 de noviembre de 2026.Playwright y Electron son marcas de sus respectivos propietarios; esta guía no está afiliada a ellos ni respaldada por ellos.

Una prueba de extremo a extremo entre el proceso de renderizado y la capa nativa

Así se prueba de extremo a extremo una aplicación Electron en GUI Test Studio, con una aplicación de facturación como ejemplo: abrir un archivo mediante el diálogo nativo, editar una línea, exportar un PDF y comprobar la notificación que dice que ha terminado.

1. 1

   Grabe la aplicación, no la página

   En GUI Test Runner-Recorder, haga clic en Grabar y elija Una aplicación.Escoja su aplicación Electron, o busque su ejecutable, y marque la casilla que la inicia con la prueba y la cierra al final, para que cada ejecución empiece con la aplicación recién abierta.Después úsela como lo haría un usuario.

   

   Ampliar

2. 2

   Abra un archivo mediante el diálogo real

   Haga clic en Abrir.Para la grabación, el diálogo de archivos de Windows es una ventana como cualquier otra: escriba la ruta del archivo en el campo del nombre de archivo y pulse Intro, y ambas cosas se graban como entrada real.Se graba una comprobación del diálogo antes del clic, así que la ejecución espera hasta que esté realmente abierto.

   Muchas aplicaciones Electron también se ofrecen como página web.Para esa versión de las mismas pantallas, el paso Subir archivo entrega el archivo a la página sin ningún diálogo.

3. 3

   Edite, exporte y lea el aviso

   Cambie una cantidad, haga clic en Exportar.Cuando aparezca la notificación, déjela un momento antes de detener: la grabación anota lo que apareció, y la prueba recibe una comprobación de ello.

4. 4

   Indique qué debe verificar la prueba

   Al detener, GUI Test Runner-Recorder pregunta qué debe verificar la prueba: los elementos en los que hizo clic, los textos, y lo que apareció en la pantalla.Deje las tres activadas.Cada paso es entonces un bloque en la línea de tiempo de GUI Test Studio, y nada en ella nombra un proceso.

Las comprobaciones que importan: texto, visual, disposición

Una grabación da a la prueba las comprobaciones que dirigen sus clics.Las que vale la pena añadir a mano detectan lo que una aplicación Electron rompe con más frecuencia.

Cada comparación ignora el ruido de renderizado que siempre hay entre dos ejecuciones, un tono más claro aquí, un borde más suave allá, y aun así detecta las regresiones reales que una persona llamaría un cambio: un icono que falta, una palabra cambiada, un botón del color equivocado.Consulte Comprobaciones visuales para saber lo exigente que es cada comprobación.

El Informe de confianza dice entonces, para cada comprobación, si el elemento se encontró y si tiene el aspecto grabado, con las imágenes esperada y encontrada una junto a otra.Para una aplicación de escritorio cuyos controles Windows no puede describir, el mismo enfoque funciona solo visualmente: consulte probar aplicaciones de Windows sin árbol de accesibilidad.

Pruebas automatizadas de Electron en cada compilación

gtr-cli, el ejecutor de línea de comandos, ejecuta la prueba exactamente como el botón Ejecutar prueba, y añade lo que necesita un pipeline: un código de salida, un archivo JUnit, y todas las evidencias de un fallo en una carpeta.

gtr-cli run tests\electron --countdown 0 --junit results\junit.xml --artifacts results\artifacts

El paso Ejecutar aplicación al inicio de la prueba lanza la compilación que se está probando: apúntelo al ejecutable empaquetado que generó la compilación, y la misma prueba comprueba cada versión que usted publica.El agente de compilación necesita una sesión de escritorio de Windows iniciada y desbloqueada, porque la aplicación dibuja en una pantalla real.La guía de CI/CD lo configura para TeamCity, Jenkins, GitHub Actions, GitLab y Azure DevOps.

Ampliar

Hay una cosa que no se aplica aquí.La función Navegadores y dispositivos de GUI Test Studio crea versiones de una prueba web para Chrome, Edge, Firefox y teléfonos emulados, como explica el artículo sobre pruebas entre navegadores.Una aplicación Electron incluye su propio Chromium, así que hay un solo navegador que probar, y las versiones que importan son sus compilaciones.

Cuándo la API de Electron de Playwright sigue siendo la herramienta adecuada

Una guía imparcial dice dónde gana la otra herramienta, y aquí gana.La API de Electron de Playwright es la elección correcta para las pruebas a nivel de código del proceso principal: evaluate() lee directamente el estado de la aplicación, un diálogo sustituido por un stub hace que una prueba del manejo de archivos sea rápida y exacta, y nada de ello necesita una pantalla.Un equipo que ya escribe pruebas de Playwright para su aplicación web conserva sus localizadores y sus hábitos en el proceso de renderizado, y ejecuta esas pruebas en segundos en cada pull request.

Las dos no son rivales.Conserve Playwright para el proceso de renderizado y el proceso principal, y una prueba de la pantalla para el recorrido que hace un usuario por la capa nativa: el diálogo real, el menú real, la notificación real, en la compilación real.Cada una detecta lo que la otra no puede ver.

Lo esencial

• 1Una aplicación Electron es una página más una capa nativa: el proceso principal se encarga de los diálogos, los menús, la bandeja y las notificaciones, y un usuario se encuentra con todos ellos.
• 2La API de Electron de Playwright llega a la página y al proceso principal desde el código, y su propia documentación dice que los diálogos nativos no se interceptan.
• 3GUI Test Studio prueba la aplicación tal como la ve el usuario: toda la pantalla grabada, el diálogo de archivos real manejado como cualquier ventana, sin compilación de prueba ni plugin.
• 4Las aserciones de texto, visuales y de disposición detectan lo que se rompe: un total equivocado, un icono que falta, un elemento de menú atenuado, una ventana detrás de otra.
• 5La misma prueba se ejecuta en cada compilación con gtr-cli, con un archivo JUnit para el pipeline; Navegadores y dispositivos es para las páginas web, aquí las versiones son sus compilaciones.

Preguntas

Electron, Playwright, Chromium, Node.js, Windows, TeamCity, Jenkins, GitHub, GitLab y Azure DevOps son marcas de sus respectivos propietarios.