Qué es TDD: Test-Driven Development

Qué es TDD: Test-Driven Development

• Básicamente es desarrollo guiado por pruebas.

• Es de finales de los 90 principios del 2000.

• NO es un lenguaje de programación es mas bien una técnica.

• Según Wikipedia: Es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring).

Objetivos del TDD

El propósito de esta técnica tiene los siguientes 3 objetivos básicos:

Minimizar el numero de bugs

Mientras mas bugs salgan menos rentable es el proyecto, porque corregir los bugs es tiempo que se puede invertir mejor en otras tareas. Si no hay bugs se puede conseguir una mayor rentabilidad de la aplicación.

Implementar las funcionaldiades justas que el cliente necesita

Es muy común que cuando se explican los requisitos de una aplicación o las especificaciones en la fase de análisis y diseño se esboza una aplicación, y el diseñador por su experencia con funcionalidades pensando que van a ser útiles para la aplicación, para el cliente o para otros componentes.

Sin embargo casi el 95% de esas funcionalidades extras no se usan en ninguna parte de la aplicación, eso implica tiempo invertido desarrollando algo que no ha llegado a nada. El objetivo de TDD es eliminar ese código innecesario y esas funcionalidades que no ha pedido el cliente, con lo cual redunda en eficiencia, tanto en el trabajo y como en la rentabilidad de la aplicación.

Producir software modular, altamente reutilizable y preparado para el cambio

Esto es realmente mas técnica, porque con buenos hábitos de programación siempre se logra que el proyecto sea modular y reutilizable.

Prepararlo para el cambio es una característica que no se consigue siempre y que con TDD si, ya que muchas veces cuando se tiene que cambiar la funcionalidad de la aplicación se tiene que refactorizar código ajeno, trabajar con código complicado, entre otras cosas; en cambio con TDD se tiene la confianza de que cuando se haga cambios no se van a estropar las funcionalidades que ya se tienen.

Esto se consigue ya que la forma funcional de TDD es que primero se construye la prueba y luego el código hace que todo lo que surga en él ya este testeado, asi que cualquier cambio que se vaya a introducir estará cubierto por los tests y si llegas a dañar algo alguno de ellos reaccionrá cuando se ejecuten.

Todo esto cambia un poco la mentalidad tradicional que es: primero analizar los requisitos, luego hacer un diseño completo y profesional, después empezar a codificar y por último testear. Lo que hay que hacer es que, en vez de planear tareas pensar en ejemplos y datos concretos, ya que en eso se basa los test, tener parámetros de entrada y de salida y luego ver si la respuesta es lo que se esperaba.

Si con TDD consigues tener en las especificaciones o requisitos una lista de ejemplos muy completa, que sean concretos, que elimine cualquier tipo de ambigüedad y que se puedan transformar en pruebas, al final tendrás una batería de tests que te cubriran todas las funcionalidades y el código resultante estará 100% cubierto por dichos test.