¿Introducción?

Hace tiempo que las siglas TDD están de moda. Test Driven Development por todos lados. Pero cuando uno se decide a ponerlo en práctica, lo único que encuentra por Mr. Google son ejemplos sencillos (HelloWorld, PetClinic, el Hospital y sus pacientes, o la última gran incorporación: Twitter en 15 minutos).

Por desgracia, cuando un developer decide probar su código, nunca (enfatizo: ¡nunca!) sirven de nada estos casos tan sencillos. A la hora de la verdad, tenemos varias bases de datos, repositorios de contenidos, conexiones a servicios SOAP (escalofrío), a servicios REST... Casos difíciles de probar, que agradecen un conjunto de buenas prácticas o ejemplos parecidos.

Es muy difícil encontrar información clara sobre por dónde empezar. Sobre dónde buscar. Sobre qué debería hacer un test (o lo que nunca debería hacer). Uno acaba teniendo la impresión que probar código de manera correcta y eficaz es un arte que se aprende con el tiempo, a base de pruebas y (muchos) errores.

Cansado de esa sensación, y después de cometer errores y más errores, quería compartir en este blog algunos ejemplos que puedan ayudar al desarrollo orientado a pruebas. Desde tests unitarios (auténtico pilar del desarrollo) a tests destructivos, intentando utilizar ejemplos reales.

Let's test! :)