Test Driven Development: Eliminando Malentendidos

Últimamente cuando alguien me pregunta por TDD acabo planteándome la misma pregunta:

¿Están interesados en la metodología de desarrollo llamada Test Driven Development o en realidad tan solo están pensando en codificar unos tests antes del desarrollo?

Parece una pregunta redundante ¿acaso no es lo mismo aplicar TDD que codificar tests antes del desarrollo de la funcionalidad?

Esta es precisamente la raíz de muchos malentendidos y la respuesta es un rotundo NO.

La Raíz de los Malentendidos

Cuando se habla de TDD en realidad muchas veces se está pensando en técnicas para  la automatización de tests de alto nivel (integración, sistema o interfaz de usuario). El interés que despierta TDD es el interés hacia las técnicas para la programación de tests automáticos, reduciendo TDD a un nombre de moda que aconseja programar los tests antes de escribir una sola línea de código funcional – lo que deja de lado aspectos fundamentales de Test Driven Development, que en realidad es una metodología con reglas propias.

Quizás el problema se deba a que la primera letra ‘T’ dirige el foco hacia el testing en lugar dirigirlo hacia la última letra ‘D’ del development (designing/coding).

Se confunde una metodología del equipo de desarrollo con una metodología del equipo de control de calidad (quality assurance).

Malentendido comprensible al formar parte del nombre de la metodología – esperemos que el cambio de vocabulario propuesto por Behaviour Driven Development con la eliminación de la palabra "test" evite este malentendido.

Test Driven Development es precisamente una metodología diseñada como herramienta de trabajo para los programadores.

No se trata de una metodología para el equipo de QA. Existen otras prácticas más directamente relacionadas con la QA como ATDD – además de prácticas específicas de Agile Testing.

Sigue leyendo

Anuncios