Que son los test environments
Los test environments, o entornos de pruebas, nos sirven para poder testear nuestras features de forma independiente al resto de equipos. Esto es útil cuando, en una empresa, varios equipos necesitan usar aplicaciones para sus pruebas e introducen modificaciones en el código para probar sus desarrollos. Si cada equipo tiene su propio entorno de pruebas, se evitan situaciones en las que el desarrollo de un equipo rompe la parte que otro necesita que funcione.
La idea es que estos entornos de pruebas repliquen nuestro entorno productivo aunque no tiene que cumplir por completo todos los casos. Podemos tener alguna dependencia externa que, para hacer pruebas, necesitemos que siempre retorne la misma respuesta para ir avanzando con nuestras pruebas. En ese caso, podemos mockear ese tipo de servicios o dependencia.
La principal utilidad de tener test environments es poder probar el desarrollo de una feature y alojar documentación sobre estas pruebas en nuestra plataforma de gestión de tareas o la que use nuestro departamento de QA para testear.
Cómo debe ser un test environment
Independiente
Como hemos indicado anteriormente, un test environment debe ser independiente del resto para poder asegurar un correcto funcionamiento al equipo que lo está usando. Esto quiere decir que cada equipo puede tener una versión de una aplicación para su uso sin que otros equipos añadan modificaciones afectando al comportamiento esperado de la aplicación. Además, a la hora de poder desplegar cambios, cada equipo es autónomo y no necesita esperar a que otro equipo suba alguna funcionalidad, fix o termine el despliegue anterior para evitar problemas.
Fácil de crear y destruir
Quizás un dilema para algunas empresa a la hora de gestionar nuevos entornos de tests es, ¿qué hacemos con la factura? Puede que su incremento no compense. La idea es que estos test environments sean fáciles de crear y destruir, con el propósito de crearlos cada día temprano y destruirlos una vez la jornada haya terminado.
Mantener el estado es importante
Cuando decimos mantener el estado nos referimos a que cuando nuestro test environment se destruye y se vuelve a crear, la base de datos permanece como estaba antes de apagar el entorno. Esto lo podemos hacer mediante una política de backups. Herramientas como Terraform (o cualquier IaC, o Infrastructure as Code) nos permiten ajustar nuestra política al respecto.
También es importante para la gestión de feature flags, ya que en ocasiones debemos tener esa flag activa cierto tiempo para ver que todo funciona correctamente, así que, si guardamos las feature flags fuera de la base de datos tenemos que proveer otra política de backup para esto.
Por qué testear tu desarrollo
El propósito principal de probar lo que desarrollamos es asegurarnos de que funciona y de que no rompe nada que ya existía antes. Cuando hablamos de pruebas, las incluimos de todo tipo, como las que el mismo desarrollador puede ir haciendo mientras desarrolla: test unitarios, de integración y e2e (tests end-to-end). Una vez estos tests pasan en verde (podemos usar TDD, BDD o el que nos parezca más apropiado), es hora de probar nuestra feature en el entorno que tenemos preparado para nosotros, recoger evidencias y poder pasar la tarea a QA para que le de un vistazo más exhaustivo o, al menos, testear desde otra perspectiva.
Testear también nos ayuda a alinearnos con los requisitos de producto. Los DoD (definition of done) nos ayudan a, con unas simples lineas, tener claro qué debe hacer la aplicación después de aplicar nuestros cambios. Y estos DoD’s deben ser testeados en nuestras pruebas para poder dar evidencias de los mismos y poder completar la tarea y desplegar en entornos reales de producción.
Una ventaja de tener estas evidencias es que si tenemos algún percance en producción, podemos rápidamente comprobar qué hemos testeado y de que forma para intentar reconocer que esta pasando en entorno productivo. Al tener las pruebas guardadas, podríamos descartar que el fallo sea debido a alguno de esos flujos que están justificados. Cuando arreglamos el fallo, debemos aportar nuevas pruebas para comprobar que se ha arreglado de la forma correcta sin estropear nada que ya había.
Consejos para testear bien
Aprender a testear es una de esas habilidades blandas que debemos ir desarrollando a lo largo de nuestra vida como programadores. Al principio estamos más confiados con nosotros mismos pero a medida que vas ganando experiencia vas interiorizando que las pruebas no están de más y que siempre es bueno añadir nuevas. Por eso, aquí van algunos consejos que pueden ser útiles:
- Como hemos comentado antes, es esencial que dejemos evidencias de nuestras pruebas. Tarde o temprano tendremos que revisar pruebas de alguna historia de usuario y, si no se han realizado, nos vamos a enfadar con nuestro yo del pasado.
- Aunque en nuestro equipo tengamos a una persona encargada de hacer el QA, pongámosle el trabajo algo mas fácil. Nuestras pruebas desde desarrollo deben ser exhaustivas (al máximo posible) porque así logramos tener mucha mas confianza con nuestros desarrollos al ver que se despliegan sin problemas, y ahorramos tiempo a nuestros compañeros de QA.
- Ayuda mucho plantear las historias bajo TDD o BDD ya que no estamos acoplando nuestros tests al código, sino que pensamos en cómo se debe comportar y luego tenemos mas flexibilidad para poder introducir el código y, si hace falta, poder refactorizar.
- Tómate tu tiempo para testear. Recuerda que el tiempo que dedicas a probar no es tiempo perdido, es tiempo que evitas arreglando algo que está roto.
¿Buscas mas consejos y trucos que ayuden a mejorar tu desarrollo? Encuentra aquí mas publicaciones de nuestros fantásticos devs y colaboradores de Secture & Code.
