BDD: la evolución del Desarrollo Dirigido por Tests (TDD)

Poner las pruebas (el testing) delante de la programación ha marcado un hito en las prácticas de programación, un antes y un después, que ha transfromado a la «cenicienta» del testing en princesa; de trabajo indeseado (probar lo que iban terminando los programadores) a tarea «cool» de diseño y pre-codificación.

TDD ha hecho que sean las pruebas las que tracen la pauta al desarrollo, y no al revés, y al hacerlo ha abierto dos dimensiones nuevas al testing tradicional: documentación, y sobre todo: diseño:

Se empiezan a escribir pruebas unitarias con herramientas como JUnit o NUnit.
Empieza a aumentar la confianza en el código, en la misma proporción que el volumen de pruebas que se va generando.
Al escribir las pruebas en primer lugar, el código gana simplicidad, programándose lo extrictamente necesario.
Las pruebas van tomando una nueva dimensión: «documentación», porque cuando se retoma código ya olvidado, son las que mejor explican qué es lo que hace ese código.
Poco a poco se empieza a descubrir la segunda dimensión: desarrollar pruebas revela el «API» del código, y pasa entonces a ser también un proceso de diseño.

A partir de este punto se empieza a plantear olvidar el origen de TDD, quitar el foco del «testing» de unidades de código, y llevarlo hacia diseño y comportamiento funcional, pasando de TDD a BDD (Behaviour Driven Development)

Básicamente es lo mismo, pero con unos cambios clave: La unidad de prueba ya no es una unidad de código (unit) sino un comportamiento. Los estados pasan a comportamientos y los marcos «xUnit» a «rSpec».

La verdad es que en nuestra industria la espiral de conocimiento está girando muy deprisa. Si tuviéramos que dibujar su avance en el campo del testing podría ser algo así: