Aceleran las pruebas, dijeron.
Y ahora, ya ha pasado casi medio a帽o, cuando reescribimos nuestras viejas pruebas funcionales sin cortar, largas e inestables y cambiamos a pruebas r谩pidas independientes de los componentes. Por lo tanto, es hora de compartir :)
Para aquellos que no lo saben, las
pruebas de componentes son pruebas que est谩n completamente aisladas del entorno global y le permiten probar ciertos casos que una prueba unitaria no podr铆a cubrir.
Hace seis meses, el lanzamiento de una funci贸n sol铆a llevar m谩s de una hora, dado que el c贸digo ha estado en el maestro durante mucho tiempo y se ha verificado completamente, pero la rama maestra no puede lograr la construcci贸n verde en bamb煤 y luego surgi贸 la pregunta, 驴c贸mo vivir?
De hecho, en este caso, las pruebas de da帽os son m谩s que buenas, pero deshacerse de ellas y "calificarlas" para las pruebas est谩 lejos de ser la mejor opci贸n :) Luego, el l铆der del equipo organiz贸 un peque帽o micro equipo:
- Timlida
- Desarrollador de backend
- Ingeniero de control de calidad
- Administrador
Despu茅s de cooperar r谩pidamente, dividimos nuestras tareas y una de ellas fue establecer un entorno para escribir pruebas de componentes. Y as铆 comenz贸 mi viaje.
Al comienzo del desarrollo, ten铆amos m谩s de 140 pruebas funcionales que se ejecutaron en varios subprocesos en diferentes entornos (Frontend, Mobile, Backend) y tomaron ~ 5-7 minutos; Tambi茅n a menudo tuvo que reiniciarlos para lograr una construcci贸n verde. Y estas pruebas ya no cayeron debido al nuevo c贸digo escrito, sino a problemas en el entorno, es decir, en alg煤n lugar que la API no respondi贸, en alg煤n lugar del microservicio de prueba, etc. Esto detuvo el trabajo de todo el departamento, ya que las asambleas comenzaron casi cada 5-10 minutos: alguien se volvi贸 a montar, alguien introdujo un nuevo c贸digo ...
Despu茅s de la primera mitad de la semana, llegamos a la conclusi贸n de que "mojaremos" nuestra API y los servicios de terceros, lo que nos dar铆a un entorno de prueba completamente aislado. Pero surgi贸 la pregunta: escribir algo propio o ... Entonces, en este "o" todo termin贸, con una breve b煤squeda, en mi camino, me encontr茅 con un peque帽o tiempo de funcionamiento en forma del servidor Mock "http-api-mock".
http-api-mock es un servidor simulado ligero y sin instalaci贸n escrito en Go con buena documentaci贸n.
Despu茅s de cientos de intentos de lanzamiento, adem谩s de profundizar en el tema de mok, logr茅 reescribir 1 prueba funcional que cre贸 un nuevo anuncio en el sitio y, despu茅s de pasar todos los c铆rculos del infierno, estaba convencido de que el t铆tulo en la p谩gina correspond铆a al t铆tulo en el cuerpo del objeto.
隆Imag铆nese ganado! La prueba reescrita result贸 ser 3 veces m谩s r谩pida que la anterior, ya que aqu铆 no verificamos la creaci贸n, la moderaci贸n, pero de inmediato devolvimos el objeto de anuncio deseado del simulacro y ganamos con 茅l. Esta peque帽a victoria se convirti贸 en un buen incentivo para un mayor desarrollo de este tema, por lo tanto, despu茅s de otra semana, tuvimos una nueva suite en codecepci贸n llamada "componente", que ya ten铆a una clase de ayuda b谩sica para trabajar con nuestro servidor Mock y se lanz贸 en ese momento yo en la caja de arena
La clase auxiliar base puede crear un anuncio en forma de un archivo json en el directorio de configuraci贸n de nuestro servidor simulado, dar el anuncio deseado por id, etc. Casi una API.
El resto de la magia nos estaba esperando m谩s, ahora solo quedaba establecer el plan de montaje en bamb煤. Para que nuestras pruebas pasen ahora por nuestro CI&CD.
El administrador nos ayud贸 con esto: con la configuraci贸n del lanzamiento de todas estas pruebas en Docker, lo que nos permiti贸 elevar nuestro contenedor con el servidor Mock para cada compilaci贸n y ejecutar nuestras pruebas en un entorno completamente aislado sin implementar nuestro c贸digo en ning煤n backend de prueba, que tampoco pudo No aceleres nuestras pruebas.
Para que toda esta magia funcione, tuvimos que agregar nuevos archivos de configuraci贸n con una nueva direcci贸n API y servicios externos, as铆 como generar una copia de la base de datos mysql y tambi茅n crear una nueva tarea en el plan de compilaci贸n con el lanzamiento de nuestro servidor simulado.
Ahora, para nuestro c贸digo, hay una API completamente nueva que, independientemente de cualquier problema ambiental, nos dar谩 lo que queremos.
Pas贸 el tiempo, las pruebas se reescribieron y 140 pruebas funcionales se convirtieron en 103 pruebas de componentes, que se ejecutan en paralelo en ~ 30 segundos.
De los pros
Muy 谩gil Debido al hecho de que son completamente independientes del entorno de prueba, no tienen que ir muy lejos para obtener datos.
Estable Las pruebas no tienen que preocuparse de si nuestra API o cualquier otro servicio cay贸 all铆, por lo que siempre estamos seguros de que el resultado nos llegar谩.
F谩cil de escribir En realidad, en el proceso de reescritura, se decidi贸 mucho copiando el c贸digo de la antigua prueba funcional al nuevo componente y preparando puntos finales para 茅l en el servidor Mock.
De las desventajas
Apoyo . Ahora, cada desarrollador que haya realizado cambios en la respuesta devuelta para un punto final espec铆fico en la API tambi茅n va al repositorio con configuraciones para el servidor simulado y corrige la respuesta all铆.
Un mont贸n de archivos . Decidieron almacenar los datos con configuraciones en forma de archivos, es decir, cada respuesta para el punto final se encuentra como un archivo y puede perderse en alg煤n lugar.
Resultados:
PruebasFue: m谩s de 140 pruebas funcionales = 5-7 minutos.
Ahora: 103 pruebas de componentes = ~ 30 segundos.
Construir estabilidadFue: cada tercer ensamblaje se cay贸 debido a alg煤n problema.
Se convirti贸: cae solo cuando el desarrollador rompi贸 la l贸gica de alg煤n m茅todo.
En los planes futuros tenemos que reescribir las pruebas de aceptaci贸n (gui), tambi茅n ejecutarlas dentro del contenedor y aislarlas del resto del entorno.