Aún son muchos programadores los que desarrollan sin pruebas automatizadas, si bien yo comencé hace pocos años a incorporar tests unitarios en mi código, a día de hoy se me hace imprescindible en cualquier desarrollo por muy pequeño que sea.
Al inicio de un nuevo proyecto, me gusta sentarme con lápiz y papel para empezar a plasmar un primer bosquejo de la arquitectura general que voy a emplear: sistemas, almacenamiento, lenguaje, organización del proyecto, pruebas de calidad, etc… Esto lleva a un sin fin de términos y dilemas que seguro ya conoces: AWS vs Azure vs On Premise, pipelines CI/CD vs manual, MySQL vs Aurora vs Oracle, SCRUM vs Kanban vs Overflow, Microservicios vs Monolítico, VUE vs REACT, Framework vs No-Framework, GitLab vs GitHub, TDD, Pruebas Automatizadas, Tests Unitarios vs Test de integración, etc… Y si a todo esto le sumas la variable de la viabilidad económica del proyecto te puede explotar la cabeza.
Lógicamente, dependiendo de la envergadura y complejidad de un proyecto las respuestas a todos estos puntos, y muchos otros, variará considerablemente. Pero con el tiempo he aprendido (a base de golpes), que hay algunos por el bien del proyecto y de mi salud mental que deben estar presentes bajo cualquier circunstancia.
Entre estos «innegociables» se encuentran las PA (Pruebas Automatizadas), y para ser más concreto dentro de esta rama, los Tests Unitarios.
La principal excusa de todo programador (incluida la mía hace ya tiempo), es que esto «suma» tiempo al desarrollo, y que por acortar plazos de entrega es preferible realizar las pruebas manualmente, o lo que se conoce como pruebas funcionales de usuario. Error… gran error. Te explico:
1.- Qué son los Tests Unitarios
Los tests unitarios, que se encuentran dentro de la categoría de pruebas automatizadas, son procesos o scripts encargados de evaluar el comportamiento de cada funcionalidad lógica de tu código, por muy pequeña que sea. Emulando por ejemplo unos datos de entrada en una de tus funciones y evaluando que la respuesta de variables o de comportamiento con la Storage sea la esperada.
Esto nos lleva a realizar tantos tests unitarios como posibilidades de comportamiento se presente en un función, clase o modelo, llegando a cubrir cada IF, cada ELSE, etc. de tu código fuente.
«Pensándolo bien…»: ¿de veras crees que eres capaz de probar cada posibilidad de tu código y tu proyecto, por muy pequeño que sea, a través de pruebas funcionales de usuario? Seguro que si eres tan cabezón como yo, tu respuesta es SI!. OK, sigamos….
2.- Evolución del proyecto
Todo proyecto vivo no deja de crecer y ser modificado día a día. Todos conocemos el efecto «arreglo una cosa, rompo cinco». En estos casos los Tests Unitarios nos van a servir para detectar rápidamente si algo de lo que hemos modificado o añadido ha afectado a otras funcionalidades que ya teníamos programadas y testadas.
«Pensándolo bien…»: ¿vas a hacer una prueba manual de TODA la aplicación cada vez que incorpores una nueva funcionalidad o modifiques una ya existente? Aquí déjame que responda yo, la respuesta es NO!, te acabarás enterando de que algo has roto cuando te lo comunique el cliente o se vea en producción pasado un tiempo 🙂
3.- Testado en todo momento
Los Tests Unitarios, suelen pasarse continuamente ya que son muy rápidos en su ejecución, lo que te garantiza en pocos segundos o minutos que tu aplicación está libre de comportamientos no esperados.
Además, suelen incluirse como condicionantes en los pipelines de CI CD, lo que obliga su ejecución antes de cualquier despliegue en entornos de Staging o Producción.
«Pensándolo bien…»: ¿Vas a hacer una prueba manual de TODA la aplicación cada vez que publiques una nueva release?
4.- Cobertura
Al programar los Tests al mismo tiempo que tu código, o incluso antes si eres un purista del TDD (Test Driven Development), estás asegurando dos cosas muy buenas:
- Una buena cobertura de tu código bajo Tests que van a estar ahí siempre presentes salvaguardando tu código.
- Un buen cumplimiento de los requisitos y especificaciones de tu aplicación: Al codificar los Tests, más aún si haces TDD, estás pensando en los casos «clave» que debe cumplir tu aplicación que seguramente tendrán origen en las especificaciones de aceptación del proyecto.
5.- La madre de los dilemas: Tiempo de desarrollo
Si todo lo demás no te ha convencido, cosa que me preocuparía, aquí viene la clave de todo. La incorporación de Tests Unitarios en tu proyecto tiene el principal objetivo aumentar la calidad de tu proyecto con la reducción de incidencias o bugs.
Si lo piensas, y seguro que te viene algún caso concreto a la mente, uno de los principales motivos por los que un proyecto puede dejar de ser rentable económicamente o incluso inviable para su evolución, es cuando tienes que dedicarle una gran parte del tiempo y de los recursos de un Development Team a la corrección de errores.
Menos errores = Más beneficio, bien económico o de tiempo para poder enfocarte en la evolución continua y no en la corrección continua.
Si te estás planteando como empezar
Si quieres comenzar a incorporar pruebas automatizadas en tu código, mi recomendación es que no te obsesiones con términos como «cobertura» o «TDD», etc. simplemente comienza… uno o dos tests unitarios para tu flamante nueva función, tres o cuatro más para la siguiente… al final te aseguro que no podrás desarrollar sin ellos.
Un saludo.
