El desarrollo guiado por pruebas (TDD, test driven development) es una metodología muy popular entre los desarrolladores. El software construido bajo esta aproximación es muy robusto y fácil evolucionar. No utilizar TDD posiblemente signifique que no se pueda alcanzar la máxima calidad posible. Ya que al aplicar el código producido consigue las importantes ventajas de TDD.
Fundamentos de TDD
La metodología TDD es bastante sencilla, básicamente consiste en escribir las pruebas que el código ha de superar, comprobar que estas fallan, implementar la mínima cantidad de código que permita pasar las pruebas y, una vez superadas las pruebas, refactorizar el código. Como se explicó al explicar las pruebas unitarias en Python. Seguir estos permite obtener las ventajas de TDD, entre las que se pueden enumerar
- Confianza
- Minimiza la cantidad de código a escribir
- Mejora el diseño del código
- Desarrollo más rápido
A continuación, se explican con mayor detalle en qué consisten estas ventajas.
Confianza
La primera ventaja es un código en el que se puede confiar. Cada una de las especificaciones implementadas tiene una prueba que garantiza su correcto funcionamiento.
Si el lector alguna vez ha recibido código para mantener o evolucionar sabrá lo complicado que suele ser esta tarea. Incluso códigos propios escritos hace pocos años. Si el código heredado no cuenta con pruebas unitarias es fácil romper de forma accidental el mismo. La existencia de pruebas unitarias, lo que garantiza TDD, ofrece una red de seguridad que evita la aparición de errores.
Mejora el diseño del código escrito
La obligación de escribir pruebas antes de implementar la funcionalidad ayuda a mejorar la calidad del código. Esto es así porque todas las funcionalidades poder probarse. Así todas las dependencias que tenga nuestra solución se han de inyectar para poder ser testeadas. Evitando la inclusión de estas en el código. Repetanso así los principios SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) de la programación orientada a objetos.
Por ejemplo, si es necesario acceder a una base de datos se tendrá que inyectar una para las pruebas. Con lo que se evita la tentación de escribir directamente el acceso en el código.
Minimiza la cantidad de código a escribir
Esta es otra afirmación antiintuitiva, ¿cómo escribir pruebas puede reducir la cantidad de código escrita? Al disponer de un conjunto de pruebas que indican lo que ha de hacer el software se evita la posibilidad de escribir código que no se va a utilizar. Reduciendo así el código incensario. Además, como indico al explicar la metodología, después de una prueba es necesario “implementar la mínima cantidad de código que permita pasar las pruebas.”
Permite un desarrollo más rápido
Parece algo antiintuitivo, si casi no hay tiempo para escribir el código. ¿Cómo escribir además pruebas unitarias puede acelerar el desarrollo? La respuesta es sencilla, al escribir pruebas permite probar más rápido las nuevas características al mismo tiempo que se comprueba que no se rompen las anteriores.
Muchas veces al añadir una nueva característica puede que rompamos las previas. Pero ¿si no se prueba cómo se puede saber que esto no es así? Posiblemente el fallo pase a producción y será necesario corregirlo más tarde.
Además, es importante recordar la mayor parte del tiempo es para el mantenimiento y evolución del código. Por lo que es clave optimizar el tiempo gastado en esta fase.
Conclusiones
En esta entrada se han visto cuatro ventajas de TDD. Posiblemente solo una de ellas ya pueda justificar la utilización de la metodología en los nuevos proyectos. Al sumar las cuatro las dudas deberían de reducirse a cero.
Pero ¿hay situaciones en las que utilizar TDD no ofrece una ventaja? Realmente en los proyectos simples que no van a requerir mantenimiento o evolución del código puede ser contraproducente.
Imágenes: Pixabay (malte1612)
Deja una respuesta