|
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
Trackback(0)
|
Luego, para profundizar un poco en esto del BDD, el libro http://www.amazon.com/Growing-...0321503627, no utiliza ningún framework BDD pero si sigue la idea básica de empezar con los test de aceptación (enfatizan mucho los test end-to-end) y luego continuar con el resto del desarrollo desde fuera hacia adentro utilizando TDD (la versión london-style, es decir, fuertemente basado en mocks). Es un libro genial porque no se queda en ejemplos y contiene un ejemplo que van desarrollando a través del libro bastante complejo. Voy por la mitad del libro y me parece un imprescindible para profundizar (no es un libro para iniciarse eso si) en el tema de BDD y TDD.