Automatización de pruebas de WPF y pruebas de interfaz de WinForms sin código (y sin árbol de accesibilidad)

Esta guía es para un ingeniero de QA o un desarrollador que tiene que probar una aplicación WPF o Windows Forms (WinForms).Muestra lo que una aplicación así le dice a una herramienta de pruebas y lo que oculta, graba una prueba paso a paso, elige las comprobaciones que sobreviven a un rediseño, ejecuta la prueba en cada compilación, y dice cuándo una biblioteca centrada en el código sigue siendo la mejor opción.

Lo que una aplicación WPF o WinForms expone a una herramienta de pruebas, y lo que oculta

WPF y WinForms describen ambos sus controles estándar a Windows mediante UI Automation: un tipo, un nombre, un lugar en la pantalla y, cuando el desarrollador lo definió, un AutomationId.Un lector de pantalla usa esa descripción, y también la usa toda herramienta de pruebas que encuentra los controles mediante localizadores.La misma aplicación también contiene controles que no dicen nada en absoluto.

La propia documentación de Microsoft dice que un control sin proveedor de UI Automation es en gran parte opaco para ella, que apenas puede informar de algo más que de su ubicación.Qué aplicaciones de Windows no tienen árbol de accesibilidad enumera los tipos de aplicación en los que esto es la regla y no la excepción.

Pruebas automatizadas de una aplicación WPF: grábela paso a paso

Las pruebas automatizadas de una aplicación WPF empiezan con una grabación, en GUI Test Runner-Recorder.No se añade nada a la aplicación: ni una compilación de prueba, ni una biblioteca, ni un AutomationId que no tuviera ya.El ejemplo siguiente graba una aplicación de introducción de pedidos, y una aplicación WinForms se graba de la misma manera.Consulte Grabar una prueba para conocer todas las opciones.

1. 1

   Haga clic en Grabar

   Abra GUI Test Runner-Recorder y haga clic en Grabar.Ponga su aplicación en el estado desde el que debe empezar la prueba: la primera pantalla del flujo de trabajo, sin nada más abierto en ella.

2. 2

   Responda a «¿Qué quiere probar?» con «Una aplicación»

   Elija Una aplicación y escoja su programa entre los que están en ejecución, o busque su .exe si todavía no está abierto.Marque la casilla que inicia la aplicación con la prueba y la cierra al final, para que cada ejecución empiece con la aplicación recién abierta.

   

   Ampliar

3. 3

   Use la aplicación como lo haría un tester

   Escriba el nombre del cliente, elija un producto en la lista, haga clic en Save y lea la confirmación.Cada clic y cada tecla se graban, y el grabador recorta una imagen de cada control en el que hace clic, justo antes de hacerlo.Pulse la tecla para detener cuando termine el flujo de trabajo.

4. 4

   Responda a «¿Qué debe verificar esta prueba?»

   Tres tarjetas preguntan qué debe comprobar la prueba: los elementos visuales en los que hizo clic, el texto de la pantalla, y lo que apareció mientras trabajaba, como un diálogo o una confirmación.Conserve los valores predeterminados para una primera prueba, y guarde.

   

   Ampliar

5. 5

   La prueba se guarda en una carpeta propia, y se ejecuta

   Una prueba llamada Orders se guarda como Orders\Orders.GTS, en una carpeta propia, donde se conservan a su lado los resultados y el historial de cada ejecución.Haga clic en Ejecutar prueba: la prueba reproduce sus clics y teclas como entrada real, dirigida al lugar donde está ahora cada control, y termina en un Informe de confianza que dice qué se superó y qué cambió.

También puede prescindir de la grabación y describir el flujo de trabajo en una petición a Claude, a ChatGPT o a un modelo de IA local, uno que proporcionamos nosotros o uno que usted aporta: la prueba se crea de la misma manera, con las mismas comprobaciones.

Pruebas de interfaz de WinForms: las comprobaciones que sobreviven a un rediseño

Las pruebas de interfaz de WinForms, como las de WPF, dependen por completo de comprobaciones que detecten un cambio real e ignoren los inofensivos.GUI Test Studio ofrece tres tipos, cada uno un bloque en la línea de tiempo de la prueba que cualquier persona del equipo puede añadir, mover o editar.

Las tres ignoran el ruido que tiene toda pantalla y aun así detectan lo que una persona llamaría un cambio: un color equivocado, un icono que falta, una palabra que cambió de mayúsculas a minúsculas, un control que se desplazó de su lugar.Comprobaciones visuales repasa la configuración de cada una.

La zona de búsqueda

Cada comprobación busca su elemento dentro de una zona de búsqueda, un área alrededor del lugar donde se grabó el elemento.La zona mantiene separados los elementos parecidos: un botón Save en la barra de herramientas y un botón Save en un diálogo se distinguen por el lugar donde está cada uno.Una comprobación que no ha encontrado su elemento en su zona al cabo de un segundo busca también en toda la pantalla, así que una ventana que se abrió más a la derecha no hace fallar la prueba, y el Informe de confianza dice dónde se encontró el elemento.

Un rediseño del código que hay detrás de un control

Un tema oscuro, un tema de alto contraste, otro idioma

La información de accesibilidad de la aplicación no cambia con un tema, así que una comprobación que pregunta a la aplicación se cumple igual en claro que en oscuro.La imagen que compara una aserción visual sí cambia, y un perfil de línea base conserva una versión esperada por entorno: ejecute la prueba con el perfil «Modo oscuro», acepte cada nuevo aspecto una vez en el Informe de confianza, y la misma prueba comprueba después el aspecto claro y el aspecto oscuro, cada uno contra la versión correcta.

Ampliar

Automatización de pruebas de escritorio en Windows en cada compilación

La automatización de pruebas de escritorio en Windows compensa cuando se ejecuta sin que nadie la ponga en marcha. gtr-cli, el ejecutor de línea de comandos, ejecuta una prueba exactamente como el botón Ejecutar prueba y responde como espera un pipeline: una prueba fallida hace fallar la compilación, un archivo JUnit llena la pestaña de pruebas, y cada imagen de lo que falló se conserva en una carpeta.

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

Una opción indica la herramienta de CI, y los fallos aparecen entonces en su propio registro, como anotaciones o como entradas de prueba, sin ningún plugin que instalar:

Una prueba de escritorio se reproduce en una pantalla real, así que el agente de compilación necesita una sesión de escritorio de Windows desbloqueada: una máquina virtual con un tamaño de pantalla fijo funciona bien.Ejecutar pruebas en su pipeline enumera todas las opciones, y Ejecute sus pruebas de extremo a extremo en cada compilación configura paso a paso una compilación de TeamCity, con el mismo comando para Jenkins, GitHub Actions, GitLab y Azure DevOps.

FlaUI, pywinauto y otras herramientas de pruebas de interfaz para WPF: cuándo el código es la elección correcta

Dos bibliotecas de código abierto son la alternativa a la que recurriría un desarrollador.FlaUI es una biblioteca .NET para pruebas de interfaz automatizadas de aplicaciones de Windows, entre ellas WPF y WinForms, que envuelve las bibliotecas UI Automation de Microsoft para una prueba escrita en C#.pywinauto, según su página de GitHub, es un conjunto de módulos Python para automatizar la GUI de Windows, con dos backends: la API de Win32, la predeterminada, y UI Automation.

Las dos son una elección razonable para un equipo centrado en el código cuyos controles son todos accesibles: las pruebas viven en el propio repositorio de la aplicación, en un lenguaje que el equipo escribe a diario, junto a las pruebas unitarias, y un desarrollador que conoce el árbol de controles puede escribir un localizador preciso para cada elemento.El coste se paga en tiempo de desarrollo, por cada localizador y por cada rediseño que cambia alguno, y un elemento que la aplicación no describe necesita otra forma de llegar a él.

Los dos enfoques no son enemigos.Un equipo con una aplicación WPF llena de controles personalizados suele mantener sus pruebas unitarias en código y grabar sus pruebas de extremo a extremo, para que las personas que mejor conocen los flujos de trabajo puedan mantenerlas, y para que también se prueben los controles que la aplicación no describe.

Lo esencial

• 1WPF y WinForms describen sus controles estándar, y no dicen nada de un gráfico, de un indicador, de una cuadrícula dibujada por el propietario ni de muchos controles de terceros.
• 2Una sola grabación prueba los dos tipos: el GTS Engine + AI pregunta primero a la aplicación y encuentra el control visualmente cuando la aplicación no dice nada.
• 3Elija comprobaciones que sobrevivan a un rediseño: una aserción visual, una aserción de texto y una aserción de disposición solo fallan cuando la pantalla está mal, y un perfil de línea base cubre un tema oscuro.
• 4Ejecútela en cada compilación con gtr-cli, en TeamCity, Azure DevOps, GitHub Actions, Jenkins o GitLab, en un escritorio de Windows desbloqueado.
• 5FlaUI y pywinauto siguen teniendo sentido para un equipo centrado en el código cuyos controles son todos accesibles; el coste es el tiempo de desarrollo de cada localizador.

Preguntas

Microsoft, Windows, WPF, Windows Forms, FlaUI, pywinauto, TeamCity, Azure DevOps, GitHub, GitLab y Jenkins son marcas o proyectos de sus respectivos propietarios.