¿Qué es TDD?
TDD viene de la sigla de Test Driven Development, o en Español, Desarrollo Guiado por Tests. Se basa en estos pasos:
- Escribir y Ejecutar el test para que falle, verificando que falle por el motivo que yo espero (ROJO)
- Escribir solamente el código estrictamente necesario para hacer pasar el test. (VERDE)
- Hacer refactor del código. (REFACTOR)
¿Por qué hacerlo fallar primero?
Probablemente se pregunten por qué escribir el test primero y hacerlo fallar. Vamos por el contraejemplo. Imaginen qué pasaría si escribieramos el código productivo, y luego escribieramos y ejecutaramos el test. Supongamos que el test queda en verde. ¿El test quedó en verde porque el código productivo está bien, o porque el test en realidad no prueba lo que tiene que probar? En cambio, si hacemos TDD, primero escribiendo el test y viéndolo fallar por el motivo que nosotros esperamos que falle, demostramos su capacidad de fallar ante código que no hace lo que tiene que hacer, y entonces demuestra su capacidad de probar nuestro código productivo.
El código estrictamente necesario
Como desarrolladores solemos tener el vicio de escribir código innecesario, o de enroscarnos y empezar a escribir condición tras condición, y una validación atrás de otra, teniendo montones de líneas de código e “ifs”, muchas veces innecesarias. Por eso es que tenemos que escribir el código estrictamente necesario y mínimo como para hacer pasar el test. Cada línea de código, cada condición, cada iteración debe estar respaldado por un caso de test que haya fallado, y que entonces justifique escribir una línea de código productivo.
Refactor
Una vez que tenemos nuestro código andando, vemos cómo mejorar su calidad. La ventaja de tener TDD es que nos da la confianza necesaria para poder cambiarlo sin miedo a romperlo. Importante, respetemos el concepto de refactor: mejorar el código sin modificar funcionalidad. Si necesitamos agregar o cambiar funcionalidad, tenemos que escribir un nuevo caso de test y seguir el ciclo rojo-verde-refactor.
¿Por qué debería empezar a usar TDD?
- Baja la cantidad de bugs
- Mejora la calidad del código
- Cubre con pruebas automáticas el código
- Obliga a pensar el diseño de nuestras APIS desde la posición del consumidor, haciendo que queden más limpias.
- Los bugs que encontremos una vez que tenemos el código ya iniciado o en algún ambiente se pueden reproducir y arreglar más rápidamente
- Reduce los costos de mantener el software a medida que avanza el proyecto.
Libros y teoría sobre TDD hay mucha, muchos artículos defendiéndola y algunos no tanto. Lo mejor es empezar a usar TDD en pair programming, acompañado de alguien que lo haya hecho antes. Si quieren seguir profundizando en la teoría, les recomiendo leer este post en dos ideas