Ir al contenido principal

Unit Testing & jMock: expectations comunes

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() {
        {
            // Expectations #1
        }
    });

    mockery.checking(new Expectations() {
        {
            // Expectations #2
        }
    });

    // ... code of the test ...
}

Gracias a esta característica de jMock, podremos refactorizar y extraer el código común en varios métodos private, dentro de nuestra clase de test. Cada uno de estos métodos contendrá uno (o varios) de los bloques de expectations compartidas. Por ejemplo:

@Test
public void testFindHousesShouldReturnHousesThatMatchColor() throws Exception {

    declareCommonExpectations(); // Expectations comunes

    mockery.checking(new Expectations() {
        {
            // Expectations of this test
        }
    });

    // ... code of the test ...
}

@Test
public void testFindHousesShouldReturnHousesThatMatchLocation() throws Exception {

    declareCommonExpectations(); // Expectations comunes

    mockery.checking(new Expectations() {
        {
            // Expectations of this test
        }
    });

    // ... code of the test ...
}

[...]

private void declareCommonExpectations() throws Exception {

    mockery.checking(new Expectations() {
        {
            // Este bloque contiene todas las expectations
            // comunes que compartirán ambos tests.
        }
    });
}

Este tipo de refactor para agrupar código común nos permitirá reducir bastante la longitud de nuestras clases de test, permitiendo que nos centremos en lo realmente importante: cuál es la entrada esperada, y cuál debe ser la salida. Sin duda, resulta especialmente útil cuando nuestra test suite está repleta de métodos findX() o updateY(), cuyo resultado queremos que sea el mismo en varias de las pruebas.

Comentarios

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

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

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