Pruebas de UI con Puppeteer: la guía práctica

En qué destacan de verdad las pruebas de UI con Puppeteer

• Control directo del navegador. Capturas de pantalla, PDF, interceptación de red, trazas de rendimiento. Cuando necesitas que el navegador haga algo concreto, este es el camino más corto.

• Scraping y automatización. Una gran parte del uso de Puppeteer no tiene nada que ver con las pruebas, y en eso es excelente.

• Una superficie pequeña y fácil de aprender. Puedes tener toda la API en la cabeza, algo más raro de lo que debería.

Los tres costos de una suite de navegador

• Los selectores se rompen. Un rediseño que no cambia nada funcional pone la suite en rojo. Ahí es donde se va en realidad la mayor parte del tiempo de mantenimiento.

• Las esperas son sutiles. Los retrasos fijos son lentos y aun así resultan inestables; esperar bien exige saber qué esperar. La mayor parte de la inestabilidad se origina aquí.

• La cobertura se escribe a mano. Cubres lo que alguien escribió, es decir, los flujos que a esa persona le parecieron interesantes y no los que se rompen.

Cómo decidir qué automatizar

El instinto es empezar por la función más importante. Un filtro mejor es cuán silenciosamente fallaría algo. Si se rompe el checkout, el fallo es ruidoso y te enterarás en menos de una hora. Si se rompe una exportación, una invitación o una página de configuración, el fallo es silencioso, y los fallos silenciosos son los que conviene automatizar primero.

Segundo filtro: con qué frecuencia cambia. Un flujo que cambia en cada sprint costará más en mantenimiento de lo que devuelve. Cúbrelo más adelante, cuando se estabilice.

Los tres hábitos que más tiempo ahorran

• Usa atributos estables. Un atributo de prueba dedicado en lugar de una ruta CSS. Este único cambio elimina la mayor parte de las roturas por rediseño.

• Espera por estado, no por tiempo. Espera al elemento o a la respuesta, nunca a un número de milisegundos.

• Verifica algo que una recarga confirmaría. Un toast de éxito no es prueba de que se haya guardado nada.

Dónde encaja la verificación basada en intenciones

La rotura de selectores y la cobertura escrita a mano son problemas estructurales, no cosas que se arreglen con más disciplina. Un paso expresado como intención sobrevive a un rediseño que un selector no sobrevive, y una cobertura generada a partir de tu producto, y no de la memoria de alguien, incluye flujos que nadie habría escrito.

Esto no es un argumento en contra de Puppeteer, que sigue siendo la herramienta adecuada para el control directo del navegador. Es un argumento en contra de escribir a mano toda esa amplitud.

Si prefieres no instalar nada, el panel hace lo mismo. Todo lo demás que puede hacer la línea de comandos está en el repositorio del CLI.

Las tres cosas que vuelven frágil un script de Puppeteer

Los scripts escritos deprisa se rompen por las mismas tres razones, y cada una tiene una solución que en su momento no cuesta nada y más tarde cuesta mucho.

Las rutas CSS encadenadas son la primera. Un selector que recorre cuatro niveles de estructura codifica la maquetación en lugar del elemento, así que cualquier contenedor que alguien añada lo rompe. Ánclate en algo que describa qué es el elemento, no dónde está.

Las esperas fijas son la segunda. Un retraso lo bastante largo para ser fiable en un día lento es un retraso que pagas todos los días rápidos, y aun así falla el día más lento de todos. Espera al elemento, a la respuesta o al cambio de estado.

Verificar lo que acabas de hacer es la tercera. Hacer clic en guardar y comprobar después que el botón de guardar existe no demuestra nada. La verificación tiene que ser algo que solo se cumple si la operación se completó de verdad, lo que normalmente significa volver a consultar el dato.

Ejecútalo en cada cambio

Si el pipeline pertenece a otro equipo, la GitHub App es el camino de menor resistencia: es un webhook, no cambia nada en tu repositorio y se dispara cuando tu build informa de que la nueva versión está publicada. Si prefieres que la comprobación se vea en el repositorio, un paso de GitHub Actions hace eso.

Dónde encaja TestSprite junto a Puppeteer

Puppeteer se queda para el control directo del navegador: capturas de pantalla, PDF, interceptación de red, scraping. TestSprite se encarga de la parte que no escala con el tiempo de quien escribe las pruebas: decidir qué cubrir y mantenerlo vivo.

Los pasos se guardan como intenciones en lugar de selectores, lo que elimina la mayor parte de las roturas por rediseño, y las esperas se gestionan solas en vez de ser algo que ajustas prueba a prueba. La cobertura se genera a partir de tu producto, así que se incluyen los flujos silenciosos que nunca entrarían en la lista de nadie.

Lo que eso cambia en la práctica: la proporción de builds en rojo que son errores reales se mantiene lo bastante alta como para que la gente siga leyéndolos, que es lo que en realidad determina si una suite de navegador sobrevive a su segundo año.