Muchas personas confunden a las "metodologías de probar primero" con TDD; es bastante común escuchar comentarios como "la esencia de TDD es escribir primero las pruebas". Y están completamente equivocados, ya que estas afirmaciones no describen para nada a TDD, y sólo hablan sobre el desarrollo con pruebas primero.
El principal motivo por el cual se confunde a TDD con el desarrollo con pruebas primero es su propio nombre: "Desarrollo Guiado por Pruebas". Si alguien que no conoce TDD tuviera que adivinar por el nombre de qué se trata esta práctica, seguramente diría que es una metodología de pruebas primero. ¡Pero no lo es!
TDD fue creado por Kent Beck (quien también inventó Extreme Programming y JUnit), y habla de mucho más. En esencia, TDD es un proceso a seguir, lo cual ya lo hace diferente a un simple enfoque de pruebas primero.
Este ciclo también se lo conoce como rojo (hacer que la prueba falle), verde (hacer que la prueba pase) y refactor. Aunque al principio pueda parecer muy parecido a un enfoque de probar primero, al combinarlo con otras prácticas y filosofías de desarrolo Ágil, TDD se convierte en un enfoque muy distinto al de probar primero, y cambia su atención de las pruebas al diseño.
TDD es una práctica de diseño, y está mucho más relacionada con el diseño emergente que con las pruebas. TDD pierde gran parte de su potencial si no se lo combina con otras prácticas y filosofías ágiles, como YAGNI y KISS. De hecho, que TDD genere una gran cantidad de pruebas es un efecto secundario positivo, pero no es su propósito final.
Para saber si estamos haciendo bien TDD debemos mirar nuestro código: debería verse limpio y claro, TDD suele generar más código de pruebas que código productivo, y deberíamos sentir que eso nos ayuda a diseñar el código.
Así que la próxima vez que hagamos TDD debemos, ¡verifiquemos no estar pensando sólo en desarrollar primero las pruebas!
