TDD es una metodología de desarrollo cuyas ventajas es crear primero las pruebas, y luego escribir el software. La mejora de la comunicación, el desarrollo ágil y la escalabilidad funcional son sus principales ventajas.
Es una metodología de desarrollo cuyo objetivo es crear primero las pruebas y luego escribir el software. Sus siglas en inglés son: Test Driven Development y en español significa: Desarrollo guiado por pruebas.
No es nada nuevo este concepto. Fue a finales de los años 80 donde se comenzó a utilizar esta metodología de desarrollo.
Para el uso del TDD se deben combinar 2 metodologías: Test-firm development (escribir las pruebas primero) y Refactoring (refactorización de riesgo). Para esto, se usa un ciclo de riesgo que consta de 3 partes principales:
1-La prueba debe fallar. (Red: Muchas herramientas muestran los fallos de las pruebas en rojo)
2-La prueba debe pasar. (Green: Al igual que lo anterior, las herramientas muestran las pruebas que pasan en verde)
3-Se debe mejorar el código. (Refactoring)
Si por alguna razón no refactorizas tu código, ya no se cumple con el ciclo de TDD y simplemente sería un Test-first development.
14 razones para hacer TDD.
a) Evita el “overengineering”: Este es un problema común con el que se encuentran muchos desarrolladores. Como su nombre indica, significa se “hace de más”. Se refiere al hecho que no todas las piezas de código son necesarias para su funcionalidad específica. El TDD ayuda a los programadores a focalizarse exactamente en lo que necesitan construir… ¡Sin caer en el “overengineering”!
b) El feedback de mi API: El TDD ayuda a tener una respuesta de la API mucho más rápida. Esta agilidad ayuda al diseño de la API porque no se necesita empezar el test desde el inicio, es un proceso acumulativo y no necesitas crear todas las capas. ¡Eso supone un ahorro de tiempo!
c) Documentación amplia: El TDD es la forma más efectiva de comunicar y sirve también para mantener un “registro” de lo que pensabas durante el desarrollo. Los métodos de testing proporcionan un dibujo claro sobre una función particular, que entra y que sale. Cuando te encuentras un código generado por terceros, vas directamente a analizar que hace el código y su responsabilidad en el conjunto del sistema.
d) Diseño emergente: No se necesita saber exactamente qué hará una clase o función. Por supuesto es mejor tener información, pero esto no significa que tu diseño estará suficiente maduro para responder bien a cambios. El proceso de refactorización se ocupa de desarrollar el diseño hasta el punto que debería.
e) “Interface” independientes: Para evitar contaminar las decisiones de diseño sobre la API, mejor que conozcas el contrato. Sin esto, el poder de la programación “object-oriented” no existe.
f) Mejora la comunicación: El TDD ayuda a la comunicación entre compañeros, un problema que está pendiente de resolver.
g) Da tranquilidad: El TDD te permite tocar cualquier proyecto sin miedo a hacerlo mal, sin miedo a que falle completamente.
h) Refactorización: Este concepto consiste en cambiar fácilmente el diseño de tu aplicación sin cambiar su funcionalidad. Desde que la función está siento testeada, hacer el TDD es la única forma de asegurar que después de cambiar el código todo funciona como antes.
i) Debugging: El TDD es la mejor manera de arreglar los “bugs”. La primera cosa a hacer es el test para reproducir el error. Cuando está hecho, es más sencillo que el “bug” no se vuelva a producir porque tiene la cobertura del test.
j) La escalabilidad funcional: A medida que la aplicación se vuelve más compleja, incrementa su coste y supone también alargar el “time-to-market”. Si no se hace el TDD, llegará un punto en que sería inviables mantener el código. La complejidad genera, además, falta de entendimiento de los componentes más complejos.
k) Satisfacción del cliente: No olvidar que siempre hay un propietario de producto o cliente esperando un resultado operativo y el TDD funciona.
l)Desarrollo ágil: Con test automatizados, consigues un “feedback” rápido además de otros muchos beneficios; durante la construcción del proyecto vemos si la estructura se rompe en algún punto o no. Esto nos proporciona una implementación de integración continua exitosa. Esto supone que el coste de implantación para construir el proyecto se reduce a cero.
m) Integración mejorada con partes de terceros: Cuando lo tienes todo bajo testeo, sufres menos para integrar partes de terceros. Fusionar es menos costos y requiere menos horas realizando el TDD.
Fuente: Just Digital Agency
Fecha: 13-07-2020
