Ir al contenido principal

¿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! :)
Etiquetas:

Comentarios

Giovi's Creations ha dicho que…
¡Felicidades por el blog y por el curro que representa para ti compartir tus aprendizajes con el resto! Giovi
21 de octubre de 2009, 11:43
Sergio ha dicho que…
Muchisimas gracias por todo este buen material que estas posteando, me esta siendo de gran ayuda en el dificil camino del TDD :)
11 de junio de 2010, 12:08
Edraí Brosa ha dicho que…
¡Gracias Sergio!

Me alegro que te esté siendo de utilidad. A ver si pronto escribo nuevas entradas, que tengo cosillas interesantes en la recámara... :)
25 de junio de 2010, 0:54

Publicar un comentario

Entradas populares de este blog

Unit Tests (I): "mocking" la interacción

Indispensables. De entre todos los tipos de tests, son los más sencillos de escribir, aunque son los que permiten encontrar (a tiempo) la mayor cantidad de bugs. ¿Qué es un Unit Test? Mejor contar qué hacen y no lo que son: Un Unit Test debe probar un ÚNICO método de una ÚNICA clase . Simple. Sin excepciones (*) . El método a probar SIEMPRE debe tener un estado inicial conocido y un resultado esperado. ¡Siempre! Si cumple ambas premisas, el test podrá ser ejecutado de forma automática y sin depender de nadie (**) . Considero que probar la interacción de una clase con el resto de componentes es uno de los sistemas que mejores resultados ofrece. Estas interacciones se "simulan" en el mismo test, utilizando mock-objects. Antes de empezar con algún ejemplo de Unit Test con Mock Objects, hay algunos consejos que nos pueden facilitar el trabajo: Cada clase debe tener su Interfaz (***) , exceptuando las java.lang.Exception y poco más. Conocer el patrón de Inyección de Depen...
2 comentarios
Leer más

Matchers y jMock

A medida que la complejidad de nuestro código aumenta, también tiende a aumentar la complejidad de los tests. Al principio nos va bien con asegurarnos que la salida del método es la esperada. Pero llegado el momento en que necesitamos comprobar qué valores contiene cada campo, o qué información se utiliza para llamar a las otras clases, es hora de empezar a utilizar Matchers . Los Matchers nos permiten especificar las restricciones o condiciones que deben cumplir los parámetros de entrada. En anteriores posts, cada vez que escribíamos with(any(String.class)) , estábamos utilizando un Matcher (uno muy genérico, que permite cualquier cadena como parámetro de entrada). Imaginemos que queremos asegurarnos que nuestro método getWeatherForecast() invoca al método getWeather() con una instancia de país, cuyo nombre debe ser el mismo que el recibido. Para ello vamos a utilizar el método hasProperty() de la clase org.hamcrest.Matchers : [...] import static org.hamcrest.Matchers.*; im...
2 comentarios
Leer más