Testing a little... in Java

Para un fanático de la Dependency Injection como yo, siempre me ha costado trabajar con Apache HttpClient 3.x y la multitud de maneras que tiene la gente de inicializar los clientes. Además, como usuario asiduo de Spring Framework , es imprescindible disponer de una manera de cargar clientes HTTP desde el contexto XML y que sea sencilla de probar. Una de las soluciones más comunes para crear y configurar los clientes es la declaración de un método init() donde se inicializan todos los parámetros, obligando que nuestra clase conozca todos los detalles y parámetros de este componente externo. Pese a que la solución funciona, no deja de ser complicada de testear, y esto es justamente lo que se quiere evitar desde el Test Driven Development (TDD). Para ello, hay que buscar una fórmula que permita "inyectar" los clientes HTTP, ya configurados en el exterior, permitiendo a la clase de destino centrarse en su objetivo. En primer lugar, hay que conseguir la biblioteca HttpClie...

En todos los proyectos aparecen métodos que necesitan realizar comprobaciones de fechas u horas en la lógica de negocio, ya sea consultando la hora actual del sistema, ya sea comparando rangos horarios. Si antes de implementar el método le damos un pensada a cómo probarlo, aparece una duda importante: ¿cómo puedo suplantar la fecha o la hora para que mis tests no dependan del día o la hora actuales? Pongamos un ejemplo sencillo: tenemos un método que si lo ejecutamos en un día par, tiene que llamar a un servicio externo. Una primera implementación, sin pensar cómo probarlo, nos daría un código parecido a: [...] public class TimeService { private IExternalService externalService = null; public void timeMethod() { Calendar cal = Calendar.getInstance(); if (cal.get(Calendar.DAY_OF_MONTH) % 2 == 0) { externalService.externalMethod(); } } [...] } Un código sencillo... ¡que resulta imposible de probar correctamente ! Como se pued...

Llega un momento en que algunos de nuestros juegos de prueba empiezan a tener muchas expectations y se empieza a complicar la implementación de nuevos tests o el mantenimiento de los existentes. Una de las consecuencias de aplicar TDD es que cuánto mayor sea la complejidad del test, mayor será la complejidad de nuestro código, y por lo tanto, de su mantenimiento. Así que si empezamos a tener tests con demasiadas expectations , es buen momento para plantearse el refactoring de alguna de las clases, para simplificar o dividir su funcionalidad. Si aún así seguimos mantiendo unas expectations muy largas, y que además se comparten entre varios tests, es muy recomendable agruparlas. Gracias a la implementación de jMock , podemos declarar varios bloques de expectations en un mismo test, de tal modo que la prueba deberá cumplir las condiciones de todos sus bloques: @Test public void testFindHouseShouldReturnOneHouse() throws Exception { mockery.checking(new Expectations() { ...

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...

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. Cansad...