Spring DBUnit

En esta ocasión vamos a hablar sobre la integración de pruebas de base de datos con DBUnit en proyectos Spring.

Si bien en este artículo ya utilizamos Spring para cargar el contexto de test de la aplicación, en el siguiente ejemplo utilizaremos el artefacto “spring-test-dbunit” para cargar los datos en la base de datos antes del test, comprobar el contenido de la base de datos después de ejecutar el servicio que queremos probar, y finalmente para dejar la base de datos en el estado que más nos interese al terminar el test. Todo esto lo realizaremos con anotaciones, sin utilizar ni una línea de código.

Para este ejemplo utilizaremos una base de datos Derby, como en anteriores ocasiones, para configurar la base de datos, puedes leer estos artículos.

Estructura del proyecto

El ejemplo que vamos a ver aquí tiene la siguiente estructura

ejemplo-dbunit

ejemplo-dbunit

Vamos a comentar brevemente cada elemento:

  • Servicio: El elemento a probar. A modo de ejemplo, hemos creado una clase que inserta un registro en la tabla “usuario”.
  • applicationContext-test: Crea un contexto de prueba para la ejecución de los test
  • log4j.properties: Configuración para mostrar las trazas en nuestros tests
  • setup: Fichero BDUnit que carga la base de datos con los registros que nos interese para la ejecución del test
  • expected: Fichero DBUnit con el resultado esperado en el test, el resultado que se quiere comprobar. Funciona igual que un assert.
  • clearTables: Fichero DBUnit para dejar las tablas en el estado que nos interese tras la ejecución del test.
  • ServicioTest: El test JUnit

Configuración de dependencias

Vamos a configurar nuestro proyecto Maven. Para el siguiente ejemplo, vamos a utilizar las siguientes librerías:

Contexto de test

Únicamente necesitamos un template, para que nuestra clase a probar realice su inserción en la base de datos y el datasource para conectarnos a la base de datos. Indicamos que queremos utilizar anotaciones y el paquete a escanear.

Clase a probar

Vamos a echar un vistazo a la clase que queremos probar. Hemos creado una clase un poco tonta que nos va a servir para entender como funciona DBUnit. Lo único que realiza la clase es un insert hardcode en la base de datos. También sacamos por el log el contenido de la base de datos tras realizar la inserción

Datos iniciales del test

Antes de ejecutar el test, vamos a suponer que queremos que la base de datos contenga una determinada información. Esto lo vamos a realizar con el archivo setup.xml. En este ejemplo únicamente hemos utilizado una tabla “usuario”, pero se pueden definir los datos de todas las tablas que necesitemos.

Resultado esperado tras la ejecución del test

Como hemos visto en la clase Servicio.java se realiza una inserción de un registro con los datos de “Raquel Martínez”, por lo tanto, partiendo de la situación inicial descrita en setup.xml el resultado esperado será el descrito en el fichero expected.xml:

Limpiando la base de datos después del test

Después de la ejecución del test, vamos e eliminar el contenido de la tabla “usuario”, para ello, hay que indicar la tabla a eliminar en el fichero clearTables.xml:

Juntándolo todo. El test

Vamos a ver como queda el test:

Vamos a analizar cada elemento. Con las anotaciones @RunWith(SpringJUnit4ClassRunner.class) y @ContextConfiguration(locations = { “classpath:applicationContext-test.xml” }) estamos indicando la carga del contexto que queremos utilizar para los test. La siguiente anotación @DbUnitConfiguration(databaseConnection = “testDataSource”) indica la conexión de base de datos que utilizará DBUnit para realizar sus consultas e inserciones. La siguiente anotación @TestExecutionListeners({ … permite indicar los lísteners que vamos a utilizar en el test, se han indicado los más típicos, aunque en este ejemplo únicamente sería necesario el primero, para que permita la inyección de dependencias y el último, para que permita la ejecución de DBUnit.

Como se puede ver, el test es muy simple, con la anotación @DatabaseSetup() indicamos los datos a cargar antes de la ejecución del test, con @ExpectedDatabase() indicamos el resultado esperado y con @DatabaseTearDown() eliminamos los datos de la base de datos. Creo que no merece la pena comentar los parámetros que reciben estas anotaciones. Podemos aplicar diferentes opciones a cada una de estas operaciones, para lo cual podemos consultar el api en esta página.

Al ejecutar el test, podemos comprobar que el test pasa y que DBUnit realiza las comprobaciones de datos necesarias. Si editamos, por ejemplo el archivo “expected.xml” y añadimos una letra en alguno de los nombres, nos encontraríamos el siguiente resultado:

Resultado Test DBUnit

Resultado Test DBUnit

Como se puede ver remarcado en rojo, DBUnit es capaz de detectar hasta el mínimo detalle. La única pega que se le puede poner a esta herramienta, es que nos puede dar algún que otro dolor de cabeza cuando insertamos/consultamos valores nulos en nuestros datos.

Bueno, aquí termina este artículo. No dudéis en poner un comentario si queréis indicarme cualquier cosa. Recordad que los comentarios son moderados, así que no aparecen automáticamente en el blog.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *