Qué necesita realmente pruebas de UI
El flujo funciona de principio a fin. Un usuario puede pasar de la intención al resultado. Nada por debajo de la interfaz puede responder a esto.
El estado entre pasos. Lo que se define en una pantalla se respeta en la siguiente. Aquí es donde se concentran los defectos reales.
Lo que se le dice al usuario coincide con lo que ocurrió. Un mensaje de éxito sin ningún registro guardado es la mentira más habitual que cuenta una aplicación.
Qué no corresponde a una prueba de UI
Reglas de validación
Probar cada combinación de entradas inválidas a través del navegador es lento y frágil.
Comprueba una en la UI y el resto en la API.
Cálculos
Una prueba unitaria responde a esto en milisegundos y con un mejor mensaje de fallo.
Preparación de datos
Recorrer cinco pantallas a clics para crear un fixture es lento y se rompe por motivos que no tienen nada que ver con lo que estás probando.
Dimensionar la suite
Dos reglas útiles. Cubre los flujos según lo silenciosamente que fallarían, no según su importancia, porque los flujos importantes están vigilados y los silenciosos no. Y deja de añadir cuando el costo de mantenimiento empiece a comerse el tiempo que estabas ahorrando, algo que ocurre antes de lo que la mayoría de los equipos espera.
Los tres hábitos
Anclajes estables, no rutas CSS. Elimina la mayoría de las roturas por rediseños.
Espera a un estado, no a un tiempo. Elimina la mayor parte de la inestabilidad.
Verifica lo que confirmaría una recarga. Elimina la falsa confianza de un mensaje de éxito.
Bajar una prueba una capa, en la práctica
El consejo de mover las comprobaciones por debajo de la interfaz es fácil de aceptar y difuso de aplicar, así que este es su aspecto en un ejemplo real.
Tienes una prueba de navegador que completa un formulario de registro con catorce entradas inválidas distintas y comprueba el mensaje de error en cada una. Tarda cuatro minutos, se rompe cada vez que cambia la disposición del formulario y no te dice casi nada sobre el navegador.
Reemplázala por una sola prueba de navegador que envíe una entrada inválida y confirme que se le muestra un error al usuario, más trece pruebas de API que comprueben las reglas de validación directamente. Ahora la prueba de navegador responde a una pregunta de navegador, las reglas quedan cubiertas de forma más rápida y más precisa, y un cambio en la validación ya no obliga a tocar nada que se renderice.
La parte que la disciplina no puede arreglar
Selectores
Un rediseño que no cambia nada funcional pone la suite en rojo.
Donde se va en realidad la mayor parte del tiempo de mantenimiento.
Esperas
Las esperas fijas son lentas y aun así inestables. Las esperas correctas necesitan saber a qué esperar.
La mayor parte de la inestabilidad tiene su origen aquí.
Cobertura escrita a mano
Cubres lo que alguien escribió, que son los flujos interesantes y no los que se rompen.
El tercero es estructural. Una cobertura limitada por el tiempo de quien la escribe se queda atrás frente a un producto cuyo código llega cada vez más de un agente. Los pasos basados en intenciones y la cobertura generada resuelven esa parte.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
El panel cubre el mismo terreno para quien no quiera una instalación local, y el conjunto completo de comandos está en el repositorio del CLI.
Conecta el repositorio desde el panel y las ejecuciones arrancan a partir del despliegue que ya generas, o añade un paso a tu propio flujo de trabajo.
Qué cubre TestSprite en cada capa
Los flujos en el navegador, donde solo un navegador puede responder, y la capa de API que hay debajo, en el mismo proyecto. Eso es lo que hace que el consejo de bajarlo una capa sea práctico y no aspiracional: las reglas de validación pasan a casos de API que se ejecutan en segundos, y un único caso de navegador comprueba que el formulario está conectado a ellas.
Ambas se generan a partir de tu producto y se refinan en lenguaje natural, y los pasos de navegador son intenciones en lugar de selectores, así que la suite sobrevive a los rediseños que no cambian nada funcional.
Lo que obtienes es una suite de navegador lo bastante pequeña como para que la gente confíe en ella, que cubre los recorridos que importan, con las reglas y los casos límite cubiertos más rápido una capa más abajo.
¿Cuántas pruebas de UI son las adecuadas?
Las suficientes para cubrir los recorridos que te daría vergüenza romper, elegidos según lo silenciosamente que fallarían. Todo lo demás, bájalo una capa.
¿Hay que probar todas las pantallas?
No. Prueba flujos, no pantallas. Una pantalla por la que no pasa ningún flujo rara vez justifica una prueba de navegador.
¿Y la accesibilidad?
Merece la pena automatizar las comprobaciones mecánicas y el resto necesita revisión humana. Es un asunto aparte, con sus propias herramientas.
¿Es necesaria la cobertura entre navegadores?
Depende de tus analíticas. Muchos equipos ejecutan una suite completa en un navegador y una suite de humo en los demás, que suele ser el equilibrio correcto.
¿Cuándo deben ejecutarse las pruebas de UI?
En cada pull request. Con menos frecuencia, un fallo apunta a un lote de cambios en lugar de a uno solo.
Prueba los flujos en la UI y todo lo demás por debajo.
Las pruebas de UI deben cubrir los flujos de principio a fin, el estado entre pasos y si lo que se le dice al usuario coincide con lo que ocurrió. La validación, los cálculos y la preparación de datos corresponden una capa más abajo, donde son más rápidos y más fáciles de diagnosticar.