top of page

TDD: Se acabó la necesidad de Testers?

Ya hablamos de Behavior Driven Development, pero qué pasa cuando los Tests guían el desarrollo?


Developer haciendo su trabajo.
TDD: Otra manera de ver el desarrollo

Buenas buenas! Cómo están? En este artículo voy a estar hablando de TDD, qué es, por qué se hace y qué significa su práctica para el tester como miembro de un equipo. Preparen un café, pónganse cómodos y vamos a eso!


TDD: Qué es?


Primero que nada, empecemos por algunas definiciones. Ustedes saben que ya hemos hablado de BDD (Behavior Driven Development), sus beneficios y uso en testing. Ahí estaba claro que el tester era uno de los "3 Amigos", junto al Business Analyst y el Developer, trabajando en conjunto para definir el criterio de aceptación y hacer el desarrollo con el testing asociado apropiadamente.


Bueno, en TDD la cosa cambia y bastante. Empezamos no por el comportamiento (behavior), sino por los tests! Así es! Es una metodología ágil de desarrollo que implica que éste comienza por la creación de tests que van a tener que hacer pasar creando la funcionalidad necesaria.


Es el famoso, rojo a verde a refactor. Esto se refiere a que, al crear los tests al principio, todos van a fallar (rojo) porque no hay nada desarrollado y luego, una vez se empieza a crear la solución, la idea es ir dejando esos tests en verde al crear lo necesario para que esto pase. Una vez todo está verde, se procede al refactor para limpiar y listo!


Pero pará...si los Devs hacen los tests, qué hace el Tester?


Ahh, esta es la gran pregunta, no? Déjenme decirles algo que leí una vez: