Pruebas de interfaz de usuario en .Net

Vivimos en la era de la evolución continua de las aplicaciones. La digitalización de los servicios ya sucedió y ahora clientes y usuarios confían en que su app para compra de billetes habitual no solo funcione para la última versión del sistema operativo de su dispositivo, sino que aproveche todas y cada una de las nuevas posibilidades del hardware: pagos con NFC, verificación de identidad con reconocimiento facial, etc. El software está más vivo que nunca y todos los días descubrimos nuevas funciones en el servicio de almacenamiento en la nube, en el correo electrónico o en la app del tiempo.Independientemente del término de moda que se nos venga a la mente, así sea DevOps, despliegue contínuo, integración contínua, etc., todos ellos descansan sobre la misma base: la confianza de que los procesos que entregan unidades de valor (desde pequeños cambios a nuevas funcionalidades) han sido probadas y están listas para ser usadas. Y esta confianza llega a través de pruebas diseñadas para ser automatizadas.

Pruebas automáticas

Las pruebas unitarias (unit tests) son bien conocidas por los desarrolladores .Net. Las metodologías «continuas» pasan por un elevado porcentaje de cobertura del código bajo el paraguas de las pruebas unitarias. Hoy en día resulta poco defendible, incluso antihigiénico, desarrollar software sin pruebas unitarias. Pero la verdadera dimensión de estas pruebas es contemplada en una línea de integración continua, desde donde con un clic se lanza un proceso de integración con build, pruebas y despliegue de forma automática.

Además de las pruebas unitarias, tenemos las pruebas de interfaz que, en algunos casos, pueden asimilarse a pruebas funcionales y a pruebas End-to-End (E2E), y son las que nos interesan en este artículo. Estas pruebas sirven para comprobar el funcionamiento de la interfaz gráfica de una aplicación ya desplegada simulando las interacciones del usuario. Es la forma de verificar un producto o servicio en su conjunto en un entorno similar al del usuario final o cliente.

Ésta es una tarea que tradicionalmente la realiza un tester. Pero como casi todo en la vida profesional, las pruebas de usuario son susceptibles de ser automatizadas. Más aún, en un proyecto software tiene todo el sentido programar las pruebas para que se lancen hacia el final de la línea de producción para dar el OK definitivo, ¿cierto? No es únicamente por el ahorro de tiempo, sino por la confianza que nos da la tecnología. ¿Tiene sentido? Sí, pero…

Coded UI Tests (CUITs)

Los Coded UI Tests (CUITs) son la herramienta que proporciona Visual Studio para conducir pruebas automáticas a través de la interfaz de usuario. No es la funcionalidad más conocida de Visual Studio, en parte porque es exclusiva de la edición Enterprise. De todos modos, en mi opinión hay otro motivo: no funcionan bien.

Mis esfuerzos de hacer funcionar pruebas de interfaz con CUITs solo me han dado frustración hasta el momento. Estoy convencido de que hay entornos en los que funcionan, pero con WPF usar CUITs no es una experiencia gratificante. El código autogenerado por Visual Studio es una repetición inacabable del comentario «Last mouse action was not recorded«. Con sinceridad no me extraña, pues los controles WPF a veces son objetos complejos con herencias intrincadas. Por ejemplo, un campo de fecha suele incluir comprobaciones internas, autocompletado, separación lógica entre día/mes/año, etc. Para hacer pruebas sobre tal control hay que estudiar bien su comportamiento, qué respuesta a eventos tiene… En definitiva, no es una tarea trivial. De todos modos, he podido saber por la comunidad de desarrolladores de Visual Studio que están teniendo problemas en Windows 10. Yo uso Windows 10 v. 1703 y he probado con Visual Studio 2015 y 2017.

Visual Studio es el mejor IDE que existe pero debo ser sincero: la idea de hacer clic sobre un área de una aplicación, que Visual Studio resuelva con un 100% de efectividad qué objeto que hay debajo del puntero del ratón y que un tester programe con él fácilmente pruebas automáticas, hoy me parece un escenario complejo. Y la confianza en el sistema de pruebas debe ser completa o no es un sistema de pruebas. Si una alarma tiene un historial de fallos, acaba por ignorarse.

UI Automation

¿Quién tiene la solución al problema de las pruebas de interfaz dentro de .Net? Éste ya no es terreno para un tester, sino para un aguerrido desarrollador. Hay que tener en cuenta que el interior de Coded UI en realidad es UI Automation, un API dentro del framework .Net que proporciona a una aplicación la capacidad de acceder y manipular los elementos gráficos de otra aplicación. Con UI Automation el desarrollador puede acceder a prácticamente cualquier elemento visual del escritorio de Windows. Además eliminamos la necesidad de disponer de Visual Studio Enterprise, poniendo en manos del desarrollador de a pie la posibilidad de programar sus pruebas de interfaz sin grandes desembolsos.

En la segunda parte de este artículo profundizaremos en este poderoso API a través de un ejemplo completo de prueba de interfaz.

Autor | Pedro Pinto – Senior Developer Soluciones Microsoft Sogeti Spain