La relación inversamente proporcional entre desarrollo Software, pruebas unitarias y regresión

El otro día, estaba meditando acerca de las pruebas unitarias y la cantidad de empresas (consultoras incluidas) que reniegan de las pruebas unitarias.
El fin último es abaratar el coste del desarrollo, ser competitivos con otros competidores y tener un time to market más corto.
Sin embargo, esto que a la postre pudiera tener “algo” de sentido, es por lo general un cáncer que se puede convertir en metástasis irreversible.

De esta manera, cuando nos encontramos delante de un proyecto Software siempre surge el eterno dilema de las pruebas unitarias, pros, contras, etc.

Una lista muy muy resumida de algunas de las conclusiones sobre aplicar o no pruebas unitarias a nuestro desarrollo sería algo así como:

Todos sabemos que hacer pruebas unitarias está muy bien.
Todos sabemos que hacer pruebas unitarias tiene un coste económico, de gestión, etc adicional al proyecto (debe formar parte de él y así lo aplico yo al menos).
Todos sabemos que hacer pruebas unitarias implica que el equipo tenga conocimientos (aunque sean básicos) de cómo realizar estas tareas (y sino, formas a tu equipo).
Todos sabemos que hacer pruebas unitarias implica dejar el ego fuera y asumir que nuestro código debe estar abierto al cambio e incluso puede estar mal diseñado y debe ser rehecho.
Todos sabemos que hacer pruebas unitarias requiere que las actualicemos y las mantengamos al día incorporando pruebas unitarias adicionales si es preciso.
Todos sabemos que hacer pruebas unitarias implica que cada vez que modifiquemos el código del proyecto y pensemos en que está a DONE, debemos estar seguros que TODAS las pruebas unitarias pasan.
Y evidentemente, todos sabemos que hacer pruebas unitarias implica que no deberíamos subir código al repositorio si las pruebas no pasan.

Y ya puestos, hacer pruebas unitarias falseando su resultado para que pasen a verde es como no poner el seguro a una pistola cargada y pegarse un tiro en el pie.
Todos sabemos que las pruebas unitarias deben ser honestas y concretas.

El caso es que como mantra queda muy bien decir que las pruebas unitarias no son opcionales, sino mandatory, pero lamentablemente muchas veces, el hecho de que en la industria Software no se aplique el mantra es culpa nuestra.
De no saber dar razones de peso suficientes para hacer ver que las pruebas unitarias deberían ir al principio de cualquier documento de toma de requisitos o de oferta económica sobre un proyecto.

El desarrollo Software por lo general no termina en una entrega del mismo, sino que sigue evolucionando.
Requisitos que cambian, necesidades nuevas a aplicar, código obsoleto que debemos desechar o cambiar, etc.

Y en todo este ir y venir aparece como variable la refactorización, ya sea para mejorar el rendimiento, mantenimiento u otra necesidad.

Precisamente sobre esto último es sobre lo que quiero apuntar que prácticamente todo el código que desarrollemos, va a sufrir en algún momento algún cambio, una metamorfosis, una refactorización,… o más bien y si eso nunca te ha ocurrido (permíteme que lo dude), debe estar abierto a esperar que ocurra.

Es por esto principalmente, que quiero agregar una razón más de porqué son necesarias las pruebas unitarias, y es que si tenemos una buena batería de pruebas que cubran la mayor parte de posibilidades que se puede dar en nuestro código (nunca diré un 100% porque siempre nos puede falta algo), podremos hacer refactorización de nuestro código sin temor.

En TDD el flujo es aplicar un modelo de test sobre el cuál construiremos la lógica de nuestro Software.
Precisamente, sobre ella, podremos refactorizar lo que consideremos oportuno de manera tal que nuestras pruebas deberían seguir funcionando dando los mismos resultados correctos.

Sin aplicar TDD, el flujo habitual es empezar por la lógica de nuestro Software, aplicar las pruebas unitarias y refactorizar, teniendo claro que las pruebas una vez más, deberían seguir saliendo en verde.

Sea como sea que escribamos nuestras pruebas unitarias, lo que es claro es que existe una simbiosis entre refactorización y pruebas unitarias, y que la una necesita de la otra.

Dicho de otro modo, escribir código sin pruebas unitarias es posible, refactorizar también, pero corremos riesgos directos e indirectos que simplemente debemos asumir, daños colaterales en nuestro código.
Los costes que habríamos asumido si hubiéramos agregado pruebas unitarias desde un principio los tendremos que pagar después y normalmente con creces, y lo peor es que posiblemente sacaremos a producción algo sobre lo que no estaremos 100% seguros de que no rompa algo.

Pero existe bajo mi personal punto de vista un riesgo aún mayor cuando o no hacemos pruebas unitarias o no hacemos bien las pruebas unitarias, y son los errores de regresión, o lo que es lo mismo, cosas que funcionaban bien en nuestro Software y que después de aplicar determinados cambios y ajustes, dejan de funcionar correctamente con la aparición de errores o bugs nuevos de cosas que antes funcionaban perfectamente.

La idea de que nuestro Software no es sólido, robusto, fiable o estable, es la que transmitiremos siempre que no cumplamos bien nuestro cometido de aplicar una batería de pruebas robustas y precisas que aseguren el correcto funcionamiento de nuestro Software.
Porque una cosa es que nuestro Software no falle y otra que sea fiable y cubra todos los requisitos funcionales para los que fue diseñado.

¡Happy Coding!