Cuando uno pregunta “qué es la automatización en el testing” típicamente se piensa en automatizar la ejecución de pruebas a nivel de interfaz gráfica, pero también incluye la automatización a todo nivel (unitario, API, etc). Además, en el testing tenemos muchas automatizaciones, no solo la ejecución: solemos automatizar procesos para la gestión de incidentes o gestión de casos de prueba, solemos automatizar la generación de datos y el cálculo de todos los pares, etc.
Dentro de la automatización de ejecución de casos de prueba, que es lo que voy a continuar poniendo foco, creo que el desafío más grande es ganar la confianza de la suite de prueba. Así como el tester o el equipo de testers debe ganar la confianza del resto de la gente, lo mismo veo que sucede con los tests automatizados. El desafío acá es mantener los tests actualizados, el mantenimiento es un tema crítico en toda automatización, y evitar así falsos positivos, lo cual hace perder la confianza.
Niveles de automatización
Todos conocen la pirámide de Cohn, por qué es mejor tener una base firme de pruebas unitarias (más rápidas, feedback más temprano, más cerca del desarrollador, más baratas de hacer y mantener) y solo tener algunas pruebas a nivel de UI que sean End-to-End. Tomo esta imagen que preparamos para un post en el blog de Abstracta.
Una cuestión que a veces se vuelve controversial es “quién tiene que hacer cada nivel de prueba?”. Quizá está más o menos claro que las pruebas unitarias las hace el desarrollador, las de E2E las hace el tester, pero las pruebas a nivel de API o Servicios? Algo que conversábamos ayer con Damián durante un curso de testing automatizado en donde colaboré con una de las clases, es que en arquitecturas de microservicios, podríamos dividir en dos niveles de API o Servicios, los más unitarios, y los que están un nivel más arriba orquestando estos microservicios, que son los que le dan la interfaz a la capa de UI. Ahí podríamos decidir que los devs prueben sus servicios más atómicos, a modo de test unitario, y el tester pruebe los servicios en donde se necesita quizá un enfoque más funcional y una visión más global. De todos modos, imagino que podrá variar caso a caso.
¿Se repiten las mismas pruebas al automatizar en los distintos niveles?
¿Qué pasa si tengo un test unitario que verifica que al crear una instancia del objeto X el atributo A no sea vacío, y luego tengo una prueba a nivel de servicio, donde en el EndPoint correspondiente a la misma creación de esa entidad X también se verifica que el atributo que corresponde con A no sea vacío, y luego tengo un test a nivel de UI que prueba qué pasa si A se envía vacío por el usuario al crear X? Estoy haciendo la misma validación cada vez, pero en distintas capas. Podemos argumentar a favor de cada una, de que queremos que se valide en la UI así no viaja un request que va a fallar, pero a su vez si los servicios se usan por otras vías, entonces también hay que controlar que eso no venga vacío, y además, los tests unitarios son los más rápidos entonces es mejor probarlo a ese nivel.
Desde mi punto de vista hay que analizar cuál es la decisión de arquitectura/diseño, y en base a eso probar los componentes como corresponde. O sea, si está definido que la UI debe controlar las entradas, entonces eso hay que probarlo, pero tal vez podríamos hacer eso solo a nivel de UI, mockeando los servicios para que la ejecución de los tests sea más rápida.
Por otra parte, hay algo que dice Martin Fowler en un post que está bien interesante, y es que si hay un test a nivel UI que detecta un error, entonces se debe agregar el test unitario que detecte el mismo error, ya que a futuro vamos a lograr que ese error se detenga antes, optimizando los tiempos de desarrollo y testing. Yo generalizaría esto, diciendo que siempre que hay un test que falla en una capa de la pirámide, hay que intentar bajarlo al nivel más bajo que tenga sentido (ya que como dije antes, tal vez estamos hablando de un test que hace validaciones sobre la UI específicamente, lo cual no tiene sentido bajarlo).
Estos son temas bastante discutidos, así que me encantaría escuchar historias al respecto!
