TDD o Test-Driven Development (desarrollo dirigido por tests) es una práctica de programación que consiste en escribir primero las pruebas (generalmente unitarias), después escribir el código fuente que pase la prueba satisfactoriamente y, por último, refactorizar el código escrito. Esto se opone a que el software se desarrolle primero y los casos de prueba se creen más tarde.

Con esta práctica se consigue entre otras cosas un código más robusto, más seguro, más mantenible y una mayor rapidez en el desarrollo.

Aunque al principio pueda parecer muy parecido a un enfoque de probar primero, al combinarlo con prácticas de desarrollo ágil, TDD toma un enfoque mucho más amplio, y cambia su atención de las pruebas al diseño.

TDD está mucho más relacionado con el diseño emergente que con las pruebas, de hecho, que TDD genere una gran cantidad de pruebas es un efecto secundario positivo, pero no es su propósito final.

El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente. Primero el cliente escribe su historia de usuario y se definen los criterios de aceptación de esta historia. A partir de aquí entramos en el bucle:

1. Se escoge el criterio de aceptación más simple y se traduce en una prueba unitaria.

2. Se comprueba que esta prueba falla.

3. Se escribe el código que hace pasar la prueba.

4. Se ejecutan todas las pruebas automatizadas.

5. Se refactoriza y se limpia el código.

Al finalizar estos pasos se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue funcionando, y posteriormente volvemos al punto 1 con los criterios de aceptación que falten y repetimos el ciclo una y otra vez hasta completar nuestra aplicación.

Open

Ventajas

• Puede impulsar el diseño de un programa. Al centrarse primero en los casos de prueba, uno debe imaginar cómo los clientes utilizan la funcionalidad (en el primer caso, los casos de prueba). Entonces, el programador se preocupa por la interfaz antes de la implementación. Este beneficio es complementario al diseño por contrato, ya que se acerca al código a través de casos de prueba en lugar de a través de afirmaciones matemáticas o preconceptos.

• Permite al programador concentrarse en la tarea en cuestión, ya que el primer objetivo es aprobar la prueba. Los casos excepcionales y el manejo de errores no se consideran inicialmente, y las pruebas para crear estas circunstancias extrañas se implementan por separado.

• Debido a que no se escribe más código del necesario para aprobar un caso de prueba fallido, las pruebas automatizadas tienden a cubrir todas las rutas de código.

• Puede conducir a un código más modular, flexible y extensible. Este efecto a menudo se produce porque la metodología requiere que los desarrolladores piensen en el software en términos de pequeñas unidades que pueden escribirse y probarse de forma independiente e integrarse juntas más tarde.

•  El tiempo de depuración se reduce en la mayoría de los casos en comparación con otras metodologías.

Desventajas

• Hay que utilizarlo y entenderlo bien para que sea realmente productivo, te ayuda a centrarte en lo importante y a no sobrediseñar, pero es importante saber refactorizar el código según vaya evolucionando para que sea consistente.

• Pruebas sobre interfaces gráficas. Aunque hay soluciones parciales propuestas, para mí TDD solo funciona en la capa de negocio, no encaja con interfaces visuales.

• Hacer pruebas de código que trabaja con base de datos es complejo porque requiere generar unos datos conocidos antes de hacer las pruebas y verificar que el contenido de la base de datos es el esperado después de la prueba.

• Un gran número de pruebas unitarias aprobadas puede traer una falsa sensación de seguridad, lo que resulta en menos actividades de prueba de software adicionales, como pruebas de integración y pruebas de cumplimiento.

• Escribir y mantener un número excesivo de pruebas cuesta tiempo. Además, los módulos más flexibles (con pruebas limitadas) pueden aceptar nuevos requisitos sin la necesidad de cambiar las pruebas. Por esas razones, las pruebas solo para condiciones extremas, o una pequeña muestra de datos, pueden ser más fáciles de ajustar que un conjunto de pruebas muy detalladas.