Reduce el tiempo de escritura y mantenimiento de pruebas en Flutter

Jul 25 2022
Todos hemos escuchado que las pruebas son de crucial importancia y tienen muchos beneficios, como mejorar la confianza y reducir los errores. Sin embargo, las pruebas de integración/extremo a extremo en Flutter a menudo requieren mucho tiempo para escribir, depurar y mantener, y se pierde mucho tiempo.

Todos hemos escuchado que las pruebas son de crucial importancia y tienen muchos beneficios, como mejorar la confianza y reducir los errores. Sin embargo, las pruebas de integración/extremo a extremo en Flutter a menudo requieren mucho tiempo para escribir, depurar y mantener, y se pierde mucho tiempo. Esto hace que las pruebas no sean un trabajo muy agradable y es tentador saltárselas (al menos para mí :/ ). Por lo tanto, reconsiderémoslo y tratemos de reducir las pérdidas de tiempo.

Ideal vs (vieja) realidad

Cerremos los ojos e imaginemos: ¿Cómo deberían ser las pruebas en un mundo ideal? Bueno, solo dile a la computadora lo que esperamos que suceda sin desperdiciar una sola palabra. Eso es todo. Luego, cuando pasan las pruebas, tenemos confianza; cada vez que fallan las pruebas, debe señalar claramente dónde falla nuestro código comercial para que podamos solucionarlo.

Sin embargo, esa no era la realidad. En el mundo real, se gasta mucho más tiempo (léase: se desperdicia) en otros aspectos de las pruebas.

Una diferencia significativa entre el ideal y la realidad es el tiempo que necesita para localizar la causa raíz de una falla de prueba, lo que puede denominarse depuración (generalizada ) . Por un lado, después de escribir una prueba, a menudo falla varias veces antes de pasar, porque nuestra prueba tiene errores o el código comercial tiene problemas. Por otro lado, la regresión (una prueba que pasó antes falla ahora) ocurre de vez en cuando, lo que indica que hay algunos problemas en nuestro código actualizado. En cualquier caso, necesitamos desenterrar la causa raíz para solucionarlo. Por lo tanto, la lentitud de la localización de errores contribuye en gran medida a la pérdida de tiempo.

Flutter integration_testtiene, bueno, una experiencia de desarrollador no excelente para esto, a pesar de que todo el marco de trabajo de Flutter es maravilloso y productivo. Considere un escenario típico: una prueba de integración/extremo a extremo toca/arrastra/desplaza muchos elementos y finalmente falla en una afirmación. Entonces, ¿cómo saber qué paso sale mal? Y mucho menos, tales fallas pueden ocurrir dentro de un CI, donde a menudo solo tenemos registros disponibles. Un enfoque puede ser leer y analizar los registros, si tenemos un sistema de registro completo, pero aún así es lento porque muchos errores se pueden detectar rápidamente mirando la interfaz de usuario o viajando en el tiempo. Observar detenidamente lo que muestra el simulador tampoco es una opción perfecta, porque los toques/arrastres a menudo ocurren demasiado rápido y esto es imposible para el modo CI. Otros detalles durante la búsqueda de causas también pueden hacer perder algo de tiempo.

También hay otros aspectos. La falta de reintentabilidad desperdicia algo de tiempo. En las pruebas de integración/extremo a extremo, los eventos no deterministas, como las solicitudes de red, ocurren con bastante frecuencia. No podemos saber cuándo terminará exactamente. Por lo tanto, las pruebas deben escribirse con esperas y reintentos. La descamación , que es natural en las pruebas de extremo a extremo, también provoca algunos falsos positivos. Nadie quiere pasar tiempo examinando el "fallo" de la prueba, solo para darse cuenta de que solo es escamoso.

Ese era el mundo real. ¿Podemos hacerlo mejor?

Una solución

Todos los dolores de cabeza anteriores me llevan a escribir una biblioteca de código abierto :

El paquete, flutter_convenient_test, trata de reducir al mínimo los procesos de pérdida de tiempo mencionados anteriormente. Sin duda, es imperfecto (y joven), pero espero que mi pequeño paso pueda ayudarlo a ahorrar algo de tiempo e inspirar más mejoras para ahorrar tiempo.

Observación: está construido sobre integration_test, por lo que aún puede usar sus paquetes favoritos como integration_test, mockito, flutter_test, etc., y migrar a esta biblioteca con modificaciones menores.

Veamos qué hace el paquete para la depuración. (Todas las siguientes características también son aplicables cuando se ejecuta en CI: generará un paquete de datos y podemos visualizarlo más tarde en el escritorio).

Para empezar, podemos visualizar todas las acciones/afirmaciones realizadas en las pruebas, con descripciones amigables.

A continuación, podemos viajar en el tiempo con capturas de pantalla. ¿Cómo se veía la interfaz de usuario cuando se tocó ese botón hace incluso 50 pasos? Ahora lo sabemos todo.

¿Quieres verlo en vivo en lugar de capturas de pantalla? No hay problema, tenemos los registros de video.

Hay más funcionalidades para facilitar la detección de errores. Por ejemplo:

  • Podemos cambiar el modo y jugar con la aplicación de forma interactiva, incluso si estamos realizando pruebas. Esto no parece fácil en la era de integration_test, y tuvimos que hacer un reinicio completo para eso.
  • Después de modificar el código, las pruebas se pueden volver a ejecutar en segundos, no en minutos.
  • Dorados mejorados: "tolerancias" configurables (permiten que una parte de los píxeles sea diferente hasta cierto punto en comparación con la imagen dorada); un panel completo para examinar las diferencias doradas con una lupa.
  • Se puede ejecutar una sola prueba o un solo grupo con un clic.
  • Para la capacidad de reintento, este paquete se inserta pumpy reintenta automáticamente cuando corresponde, por lo que no hay necesidad de que los humanos intervengan y escriban código.
  • Cuando se trata de descamación, la biblioteca lo comprende completamente y no lo verá erróneamente como fallido (y tal vez un gran error rojo en CI) ni considerará que ha tenido éxito.

En resumen, hemos visto que las pruebas en Flutter contenían algo de tiempo perdido, incluido el tiempo adicional para localizar las causas de los errores, la falta de reintento y la descamación. Por lo tanto, hice flutter_convenient_test tratando de reducirlo al mínimo. Espero que pueda ahorrar su tiempo!

© Copyright 2021 - 2022 | unogogo.com | All Rights Reserved