Normalmente, denominamos test de integración, aquéllos que prueban todas las clases que intervienen en una operación, osea que no ocultamos nada a la acción de test, y ha de recorrer los mismos caminos que recorrería la aplicación en produccion.
Cuando estos test son de una aplicación con intervención de operador (Front y back), necesitamos otros recursos, uno de los más conocidos, Selenium, pero en este caso que nuestra aplicación es una simple API, nos quedaremos con los servicios de Junit5
Presentando la idea
Puede que haya simplificado un poco la problemática; los test de integración son los más complejos de realizar, entre otras cosas, por la cantidad de clases que intervienen, y lo difícil que es preparar el entorno, y, eso hace, que habitualmente, no sean los programadores de la aplicación los que realizarán esta parte del proyecto, porque SI, ES UNA PARTE DEL PROYECTO.
De cualquier forma, y, aunque sea para nuestra tranquilidad, a mi me gusta preparar alguna prueba que me facilite esa visión de conjunto de que «todo funciona», tan necesaria para nuestro espíritu
La base de datos
Vamos a necesitar una base de datos, pero…deberá ser un poco especial; dejando aparte lo de que «no puede ser la de produccion», tampoco es facil hacerla con la de desarrollo, debido a la necesidad de controlar el contenido, y que no haya coincidencias con otros programadores
Las soluciones mas sencillas son dos:
- Utilizar la misma BBDD que utilizaremos en produccion (el mismo motor!, (MySQL, MariaDB, Oracle…) encerrada en un container que podamos regenerar en cada test. Esta solucion es necesaria cuando utilizamos SQL propio de ma BBDD
- Utilizar la BBDD H2, en memoria, que nos facilita directamente SpringBoot
Y nosotros, en este caso, vamos a optar por la base de datos en memoria H2, por lo que la incluiremos en el pom.xml
La hemos incluido solo para test, por lo que cuando generemos la version de produccion, esta librería no se incluirá
Necesitamos facilitar la configuración a SpringBoot, y eso lo hacemos, creando un application.properties en la carpeta resources que se encuentra dentro de la carpeta de test.
Toda la información indicada en ese fichero, solo se utilizará en la configuración de test, y no afectará a nuestro codigo de producción
En ese fichero, podemos indica, por ejemplo:
La BBDD será efímera, creándose y borrándose en cada ejecución, y no me he molestado en utilizar usuario y contraseña, ya que los datos que contendrá, también son falsos
El resto de información es la habitual, aunque el puerto, no valdría la pena, y la url se podría simplificar.
Ya solo con esto, si lanzamos el test, veremos como se crean las tablas necesarias, por lo que debemos empezar a pensar en los datos
Nuestra plataforma, es capaz de crear registros, por lo que podríamos dejar la BBDD vacía, y, antes de cada test, o en el que nos interesará, podríamos dejar el codigo para crear registros, y, vereis que puede ser muy interesante, pero, para esta version, cargaremos la BBDD durante el arranque de Spring.
Para ello, en la carpeta de resources, podemos crear un fichero llamado data.sql y dentro, podemos poner cosas como estas
Si necesitaramos crear el esquema también, podemos utilizar otro fichero (schema.sql), dejando las instrucciones, pero en nuestro caso no será necesario
Con esto, ya contamos con una BBDD configurada y cargada, apunto para realizar nuestros test, pero debemos acordarnos que dentro de nuestra pasada de test, la base de datos puede cambiar de contenido, cuando creemos destruyamos o modifiquemos tablas. No es la situación ideal, pero la vamos a aceptar en este caso.
Nuestro siguiente paso: Empezar a escribir el test
Conclusión
Ahora ya tenemos preparado nuestro entorno, para poder hacer pruebas mucho las reales, y de todos los módulos del CRUD
Este desarrollo esta hecho para disponer de un fuente para explicar otros temas, tal y como se indica en Visión de conjunto con Spring
Todos estos articulos se encuentran en GitHub
Descubre más desde Recursos para formacion
Suscríbete y recibe las últimas entradas en tu correo electrónico.
