Se necesitan pruebas automáticas en proyectos. Pero, como dicen, la automatización del gusto y el color puede ser diferente. Llegamos a un proyecto donde ya había pruebas automáticas y pudimos mejorar la cobertura y acelerar el paso de las pruebas sin una revolución fundamental. Debajo del gato sobre cómo lo hicimos.
Algunas palabras sobre el proyecto.
Aunque no podemos revelar los detalles del proyecto debido a la NDA, en términos generales, la tarea fue la siguiente. Nos unimos al desarrollo del servicio API fintech, que interactúa con la base de datos, devolviendo los objetos financieros necesarios (precios, tarifas, etc.). Nuestra tarea consistía en probar clientes móviles para este servicio, tanto aplicaciones móviles nativas como web.
La automatización de pruebas en este proyecto se desarrolló gradualmente, junto con la complejidad del servicio. Esta es probablemente la duración de las pruebas de principio a fin, que encontramos en el proyecto. La mayoría de ellos no funcionaban en ese momento, porque el servicio había cambiado y no había nadie para respaldar las pruebas: el único ingeniero de automatización dejó el proyecto mucho antes de que llegáramos.
Incluso aquellas pruebas que parecen corresponder a la funcionalidad a veces caen debido a la confusión con las versiones o la inaccesibilidad de los recursos externos. Para las pruebas, se utilizó una infraestructura separada: bancos de prueba, donde se implementaron las versiones necesarias para los experimentos. Diferentes grupos de trabajo tenían acceso a él, y no siempre actuaban en concierto. Como resultado de las acciones de un grupo, algunas API importantes utilizadas por nuestro servicio podrían caerse, por lo que incluso una prueba de trabajo dejó de pasar. Es decir la prueba ya no mostró la capacidad de servicio del servicio en sí, sino que se relacionó con la infraestructura de prueba en su conjunto.
Como llegamos al caos
Parecería que en esta situación es necesario abandonar todos los logros anteriores y construir nuevamente las pruebas. Pero actuamos más "humanamente". La estructura de la prueba en sí se preservó, enfocándose en resolver problemas específicos: la aprobación lenta de las pruebas, su inestabilidad y la cobertura insuficiente de los casos de prueba. Para cada uno de ellos había una solución.
Refactorización
En primer lugar, modificamos parcialmente el código de las pruebas antiguas, confiando en patrones de diseño más modernos.
Parte del código heredado tuvo que eliminarse; era demasiado difícil de mantener. En otra parte, descubrimos todas las debilidades: reemplazamos el sueño predeterminado con camareros normales, hicimos preparativos para todas las pruebas en la configuración global a través de anotaciones de corredores de prueba, etc. Muchos pequeños pasos redujeron el promedio de prueba de punta a punta de 3 a 4 minutos.
Enfoque atómico
Para acelerar la creación de nuevas pruebas y simplificar el soporte de las antiguas, hemos pasado de casos engorrosos de principio a fin.
Personalmente, no tengo nada fundamental en contra de las pruebas de extremo a extremo, sin embargo, en el caso de que necesite verificar una pantalla específica (o incluso parte de la información que contiene), seguir todos los pasos, comenzando con la autorización del usuario, es demasiado costoso. Imagine que estamos probando una tienda en línea y solo necesitamos verificar el cheque que se enviará al comprador después de comprar un determinado producto. En lugar de obtener solo una pantalla del sistema, deberíamos ingresar por usuario y contraseña, seleccionar un producto, confirmar una compra, etc. - realizaría muchos pasos que no están relacionados con una tarea de prueba específica. Pero cada paso lleva tiempo. Incluso con toda la optimización llevada a cabo, el lanzamiento de la prueba de extremo a extremo tomó hasta 2 minutos, mientras que la verificación de una pantalla específica tomó solo 10 segundos. Por lo tanto, donde fue posible, pasamos a tales controles "atómicos", refiriéndonos solo a la pantalla que nos interesa como parte del caso de prueba.
En el camino, solo para comparación de pantalla, implementamos pruebas de instantáneas, que le permiten verificar la mayor parte de la interfaz de usuario. Al tener las pruebas y el código de la aplicación en un repositorio, podemos usar los métodos de esta aplicación en las pruebas, es decir. plantear cualquier pantalla que sea necesaria en este proceso. Entonces podemos encontrar errores al comparar capturas de pantalla de prueba con las de referencia.
Ahora tenemos alrededor de 300 pruebas de instantáneas, y su número crece gradualmente, ya que este enfoque puede reducir significativamente el tiempo que lleva verificar la versión terminada antes de enviarla a producción. Todo este conjunto de pruebas comienza automáticamente cuando se abre la solicitud de extracción y se ejecuta en 40 minutos, por lo que los desarrolladores reciben rápidamente comentarios sobre los problemas en la rama actual.
Por supuesto, se han preservado varias pruebas de extremo a extremo. No puede prescindir de ellos donde necesita verificar escenarios de grandes negocios, pero tiene sentido ejecutarlos cuando ya se han verificado todos los detalles.
Burlándose
Para excluir la influencia de un banco de pruebas inestable en el resultado del lanzamiento de nuestras pruebas, lanzamos un servidor simulado. Sobre las decisiones que luego consideramos y por qué elegimos Okhttpmockwebserver,
ya escribí sobre Habré .
Como resultado, la proporción de caídas episódicas debido a causas externas de las pruebas disminuyó significativamente.
Kotlin DSL
Paralelamente, hicimos las pruebas más legibles.
Aquellos involucrados en las pruebas de IU saben lo difícil que es encontrar la verdad entre un grupo de localizadores en el largo "paño" de la prueba (especialmente en la etapa en que todavía eran pruebas de extremo a extremo). Es fácil navegar en ellos cuando has estado en un proyecto durante dos años e incluso en medio de la noche puedes recordar qué es qué. Pero si acabas de llegar, pasar a lo que está sucediendo es una gran tarea separada. Para que las personas nuevas no tengan que lidiar con eso cada vez, decidimos cambiar a Kotlin DSL. Se implementa de manera bastante simple y tiene una estructura simple y comprensible. Si antes las pruebas consistían en un conjunto de llamadas idénticas de bajo nivel: clics, entrada de texto, pergaminos, ahora todo esto se ha convertido en algo más "comercial", algo así como un enfoque BDD. Todo es visible y comprensible.
En mi opinión, esto nos hizo una cierta reserva para el futuro. Este proyecto ya enfrentó una vez la partida de un solo ingeniero de automatización. Para las pruebas, esto no terminó de la mejor manera: simplemente dejaron de admitirlos, porque el umbral de entrada resultó ser demasiado alto. Entender un código tan seco requería mucho tiempo y una cierta calificación. Rediseñamos las pruebas de tal manera que sea posible transferir rápidamente personas de otros proyectos o de pruebas manuales a automatización en cualquier momento. Casi cualquier persona puede escribir las pruebas más simples en Kotlin DSL. Por lo tanto, la automatización puede abandonar la implementación de bajo nivel y escribir rápidamente nuevas pruebas simples para conectar a las personas del equipo funcional. Tienen suficiente conocimiento de la lógica de negocios, y el proyecto se beneficiará del hecho de que estarán más involucrados en el proceso de redacción de pruebas automáticas. Kotlin DSL le permite describir casos de prueba exactamente como les gustaría ver todas las comprobaciones, dejando la implementación de bajo nivel de métodos fuera del alcance de su trabajo.
En general, todo esto permitió aumentar la cobertura de las pruebas automáticas más rápido. Si antes tomó 16-20 horas implementar el nuevo conjunto de pruebas, entonces con el nuevo enfoque, dependiendo de la complejidad de las pruebas, lleva de 4 a 12 horas (y los costos de mano de obra para el soporte se redujeron de 16-24 a 8-12 horas en semana)
Autor del artículo: Ruslan Abdulin.
PD: publicamos nuestros artículos en varios sitios de Runet. Suscríbase a nuestras páginas en
VK ,
FB ,
Instagram o en el
canal Telegram para conocer todas nuestras publicaciones y otras noticias de Maxilect.
PPS Ayúdenos a hacer que los artículos de nuestro blog sean más interesantes:
docs.google.com/forms/d/e/1FAIpQLSeqnPceNuK-JopYVxgF15gNWLIi5oM_AZesioCDGXhvr7Y7tw/viewform .