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í:

Más información

Herramientas BDD

• Java: JBehave , JDave , Instinct , beanSpec
• C: CSpec
• C#: NSpec
• .NET: NSpec , NBehave
• PHP: PHPSpec
• Ruby: RSpec , Shoulda , test-spec & Bacon , Cucumbe
• Javascript: JSSpec , jspec

• Vídeo e introducción a BDD de Dave Astels (inglés).