Los test de integración son esa parte de la programación donde nos solemos atascar o dejar de lado en el proceso normal del desarrollo de aplicaciones, pero es un apartado muy importante de todo el ciclo de vida del software. Este post viene a raíz de un mensaje que me llego a la web a través del apartado /ama para hacer preguntas anónimas.
Índice
Recuerda que si tienes cualquier pregunta me la puedes dejar de forma anónima en el siguiente enlace https://www.netmentor.es/ama.
1 - Qué son los test de integración?
No quiero entrar mucho en detalle sobre qué son los test de integración o como implementarlos pues tengo un post al respecto.
Lo que sí que quiero mencionar es que en diferentes empresas se llama test de integración a todo lo que integra servicios externos, ya sean la base de datos, el sistema de ficheros, u otro servicio interno de la empresa.
Y ya bien estes testeando en local con las dependencias en docker, apuntando a dev desde local, o ejecutes las pruebas dentro de un entorno, estás testeando las dependencias. Así que en muchos casos, todo lo que no sea un test unitario, va a ser un test de integración, y así lo vamos a tratar en eeste post.
2 - Los test de integración son útiles o causan más problemas que beneficios?
Aquí viene la pregunta, que me ha parecido lo suficientemente interesante para hacer un vídeo:
Se que muchos vais a saber la respuesta antes de que diga yo nada, pues la gran mayoría de los que leeis este blog o veis mi canal de youtube tenéis muchos años de experiencia. Pero creo que le puede ser muy útil a mucha gente.
Y la respuesta rápida es que sí, son muy útiles. Normalmente respondo a los /ama en un tweet y arreglando, pero para este quiero añadir una explicación de por qué son útiles.
El motivo es obvio y es que ayudan a comprobar que todo el entramado de tu aplicación funciona como es esperado. En cada entorno.
Es aquí donde viene lo importante, la pregunta del AMA viene diciendo que testear una base de datos con mysql muy bien, que está en docker. Pero qué pasa si tenemos algo en Azure (cosmosDb), etc.
Podemos mencionar dos partes.
La primera es que puedes utilizar Azurite en local para emular Azure en tu máquina. En AWS existe localstack. Aún así, hay muchas empresas que dan acceso al entorno de dev desde local, para ahorrar todo el tema de configuraciones individuales en proyectos, etc. que a la larga sale mucho más fácil.
La segunda y más importante, lo principal de los test de integración es que funcionen en los entornos de producción. Qué funcionen en tu máquina local está bien, claro, porque es donde creas el test. Pero donde de verdad importa es que funcione en PRODUCCIÓN.
Esto es debido a que un sistema bien montado tiene que tener los permisos justos y necesarios, nunca más y nunca menos. Lo que comenta el mensaje de “están sujetos a que nadie haya metido mano”; para eso tienes los tests. De hecho es el mejor motivo que puedes encontrar, de esta forma si algo funciona en la implementación actual, despliegas el código nuevo, y no va, sabes que alguien ha metido mano y tienes que volver a la versión anterior.
Cuantos más entornos tengas mejor, ya que si tienes un error en uno, debería suceder en todos ellos. (Exceptuando problemas de comunicación/configuración de la app).
Un ejemplo de un error común es que tengas que acceder a una tabla donde no tienes permisos. En tu máquina todo funciona bien porque tienes acceso a todo, y en los test unitarios estas haciendo un mock de la bbdd. Así que una vez despliegas te das cuenta que hay test que fallan, y al mirar los logs, puedes observar que te da un error de acceso a cierta tabla.
2.1 - Formas de ejecutar los test de integración.
En mi opinión hay dos formas de ejecutar los test de integración; ambas son similares pero no son exactamente iguales. Una es más “segura” que la otra, pero requiere más configuración.
Tener los test de integración (o end to end) en un proyecto separado.
Esto significa que los test son completamente independientes al código, tanto en código, como en despliegue.
Esto significa que cuando tu haces un cambio en el código, el test NO SABE qué has cambiado nada, ya que es un proyecto totalmente distinto.
El proceso puede ser algo como lo siguiente; realizas un cambio, se aprueba la Pull Request, hacer el merge y en la CI/CD se crea el paquete para que puedas desplegar (o se despliega automáticamente) en el entorno de desarrollo.
Una vez se despliega en este entorno, debemos ejecutar los test, ya bien se ejecuten de forma automática o manual o una persona específica para QA. Debemos esperar a que termine y que todo esté bien para seguir propagando el cambio a través de la pipeline, que en este caso es una mezcla de manual y automático.
Repitiendo este proceso en cada entorno que tengamos.
Cuando todo va bien, al terminar damos el visto bueno y ya. Y si algo falla lo que tenemos que hacer es un rollback del cambio actual y desplegar la versión antigua.
Puntos clave de esta implementación:
- Los tests están en un proyecto separado, por lo que si algo cambia en la app, debemos actualizarlos de manera independiente. Si tenemos un cambio de funcionalidad que genera un breaking cambio, el test se va a romper.
- En muchas empresas son un paso manual, no se hace automático, y hay que verificar el resultado para ver que todo ha ido bien.
- No se ejecutan en la pipeline principal de la aplicación, por lo que podemos tener una aplicación que no funciona bien desplegada en producción.
- Al no estar directamente enlazado el test con el servicio al que hace referencia, muchas veces son olvidados y no son actualizados.
La segunda forma es tener los test de integración en el propio proyecto. Ojo, si vienes de C# No estoy hablando de hacer test a una API con testserver ya que esta funcionalidad lo que hace es levantar una copia de tu aplicacion en memoria, sino a que como tanto un proyecto adicional en nuestro repositiorio y un paso en CI/CD tengamos unos tests que hacen llamadas http reales al servicio.
Idealmente podríamos combinar el despliegue con un Blue/Geen release donde tenemos tanto la instancia nueva como la antigua siendo ejecutadas en paralelo, configurando el load balancer para que nuestras llamadas vayan siempre a la nueva versión. A su vez, la pipeline tiene el paso de ejecutar el test, y una vez lo ejecuta y todo funciona bien, Reemplazamos las instancias existentes por las nuevas, y si algo falla, deshacemos el cambio en el load balancer para que las viejas sigan donde están en vez de las nuevas.
Puntos clave de esta implementación
- Los tests están en el propio código.
- Tests completamente automatizados dentro de la propia pipeline.
- Mucha más configuración dentro de CI/CD. (mayor gasto de recursos)
- Los errores no llegan al entorno de producción. Ya que si algo no va bien lo detectaremos en los tests, y como el load balancer sigue apuntando a la instancia vieja los clientes no se verán afectados.
Al final qué opción utilizar depende de dos factores principales. De los recursos, tanto económicos como de personal, porque no es barato y hay que mantenerlo. Y de cuánta importancia tiene que un servicio no funcione al 100% durante unos minutos mientras haces los test y despliegas la versión anterior.
Lo más normal es trabajar en empresas que hacen la primera opción, pero también he trabajado en una donde usábamos la opción dos.
Si te gusta la forma en la que este post está escrito, tengo un libro para aprender sobre sistemas distribuidos siguiente la misma fórmula el cual se puede comprar en el siguiente enlace: https://www.netmentor.es/libros/construyendo-sistemas-distribuidos
2.2 - Utilizar exclusivamente test de integración
Quiero terminar dando mi opinión sobre los proyectos o empresas que utilizan únicamente los test de integración. Ya que existen. Si la empresa es pequeña, o una startup, lo puedo entender, ya que un test de integración va a comprobar que todo lo que tiene que funcionar funciona.
Aún así, es mucho más sencillo realizar test unitarios, ya que como su nombre indica, testeas una única funcionalidad, puedes simular diferentes tipos de respuestas de las dependencias, etc.
En resumen, ambos tipos de tests tienen su mercado y ambos son necesarios para el correcto funcionamiento de nuestra aplicación.
