El desarrollo dirigido por las pruebas TDD (por sus siglas en inglés Test Driven Development) es un enfoque de desarrollo de software en donde el desarrollo de las pruebas se entrelaza con el desarrollo del código. Esta práctica se introdujo como parte de los métodos ágiles, sin embargo, puede ser usada también en una metodología guiada por planes (como el MCS-OpenUp).

En el desarrollo dirigido por las pruebas es necesario implementar las pruebas para el componente o incremento ANTES que el propio componente sea implementado. Además, no es posible avanzar con la implementación del próximo componente o incremento hasta que el incremento actual no pasa las pruebas.

El proceso de TDD básico se presenta en la siguiente imagen:

Los pasos en este proceso son los siguientes:

1. Se identifica la funcionalidad, ítem del backlog, componente, incremento o unidad a ser implementada (éste debe ser pequeño e implementable en pocas líneas de código).
2. Se escriben una o varias pruebas para la funcionalidad identificada. Estas pruebas deben ser implementadas como pruebas automatizadas, para poder ejecutarse y reportarse de forma automática, tanto si pasan como si fallan.
3. Luego se ejecutan la pruebas implementadas Inicialmente, cuando la funcionalidad aún no está implementada, las pruebas van a fallar. Esto es deliberado y muestra que las pruebas implementadas agregan valor al conjunto de casos de prueba ya existente.
4. Luego se implementa la funcionalidad y se ejecutan las pruebas nuevamente. Si las pruebas fallan, será necesario o bien corregir, refactorizar o agregar nuevo código al ya existente, con el objetivo de pasar las pruebas que fallaron.
5. Una vez que todas las pruebas pasan, se puede avanzar a la implementación de la siguiente unidad o incremento.

Es importante tener un entorno automatizado de pruebas como JUnit (si la tecnología a utilizar es Java), NUnit (si la tecnología es .Net) u otros ambientes que puedan ser compatibles con las tecnologías utilizadas en el proyecto.

Uno de los argumentos que soporta el desarrollo dirigido por las pruebas es que el desarrollar las pruebas antes de desarrollar el programa ayuda a los programadores a aclarar sus ideas acerca de lo que realmente debe hacer el programa. Para escribir una prueba, es preciso entender qué es lo que se quiere (cuál es el comportamiento esperado del programa) y esta comprensión ayuda al desarrollo posterior del programa. Además de una mejor comprensión del programa, otros beneficios del desarrollo dirigido por las pruebas son:

1. Cobertura de código: con esta metodología, cualquier código desarrollado debe tener al menos una prueba asociada y esto asegura que todo el código es ejercitado (al menos mínimamente). Como el código se prueba a medida que se escribe, los defectos son detectados de forma temprana y oportuna.
2. Pruebas de regresión: Un conjunto de pruebas se va desarrollando de forma incremental a medida que el propio código se va desarrollando. Esto permite que en cualquier momento se puede correr ese conjunto de pruebas (como pruebas de regresión) para confirmar que los cambios realizados al sitema no introdujeron nuevos errores.
3. Depuración simplificada: cuando una prueba falla, es mucho más fácil detectar dónde está el problema, que en la mayoría de los casos, refiere al código recientemente escrito. Esto economiza el tiempo invertido en la depuración del código (debbuging). Reportes de investigación indican que rara vez es necesario el uso de depuradores automáticos para equipos que utilicen la metodología de desarrollo dirigida por las pruebas.
4. Documentación del sistema: las pruebas en sí actúan como una forma de documentación que describen lo que debe hacer el código. Leer las pruebas suele facilitar la comprensión del código.

Tener las pruebas automatizadas de todas las funcionalidades que se van agregando al sistema disminuye de forma dramática el costo de las pruebas de regresión, que resulta ser muy alto cuando se tienen que realizar de forma manual y al realizar una selección se corre el riesgo de olvidar alguna prueba importante. Una buena práctica en el desarrollo dirigido por las pruebas, es que ninguna nueva funcionalidad o incremento se integra al sistema estable sin que todas las pruebas automatizadas sean ejecutadas con resultado exitoso. De esta forma, se asegura que la nueva funcionalidad integrada no generará problemas en el código ya existente.