En el artículo anterior, preparamos el entorno, ahora, vamos a escribir el test.
Vimos que dejábamos configurada una base de datos (H2 concretamente), por lo que, quizás lo mas sencillo, sería partir del módulo que escribimos como testSpring, y hacer que el trabajo que hacíamos con cineService falseado con Mockito, lo dejáramos como en produccion, esto es, permitiendo que lo hiciera el Dao que hemos escrito, que además, llamaria al repositorio, por lo que probaríamos todo el trabajo
Cambiamos la anotación de la clase, y nos queda
En linea 43, definimos el entorno, y de paso, pedimos que la ejecución se realice en cualquier puerto que esté libre.
En la linea 45, solicitamos que el test se realice en el orden que indiquemos con numeración (@Order)
En linea 49, autoconfiguramos MockMvc que seguiremos necesitando para hacer las llamadas al controlador.
y fijaros que hacemos desaparecer las lineas que se muestran abajo, de TestSpring, ya que NO vamos a falsear las respuestas de CineServicio
Ademas, en las lineas 54-56 optimizamos las constantes que vamos a utilizar, para que no sean tan largas, y en la 57, indicamos el número de registros que tenemos, por si necesito contarlos alguna vez
Definimos los datos que nos interesen, y, aunque los definimos como objetos, también los necesitamos en JSON para poderlos enviar, de forma que quedan
Como en la version anterior, debo crear objetos que definan los errores, ya que deben ser detectados por los filtros de la aplicación. Debemos tener en cuenta, que esta vez los datos se van a grabar, por lo que deberemos cuidar que leemos y que grabamos. y, eso, también causa que me interese el orden de ejecución, ya que para saber si funciona el leerTodos, necesito saber lo que me voy a encontrar, y, si los test se realizan de forma aleatoria, el test de POST y de DELETE, me puede causar problemas, ya que depende que se ejecute antes o después, cambiará el contenido de la tabla…. . Lo mismo pasa con la prueba de error del test leerTodos…., debo borrar todos los registros para que se genere el error.
Si, hay otras formas, pero ahora lo haremos así.
Una vez aclarado esto, el primer test que haré es
Le he indicado que es @Order(1), y he solicitado que obedezca el orden numérico….por eso se ejecuta el primero.
La linea 146 es una pequeña rutina que lista el contenido de la tabla, con idea de ver como va todo, y, que puede ser borrado en cuanto el test funcione.
En la linea 147, puedo hacer el Get y espero la respuesta para comprobar que existen DATOS, que hay campos de todo el array que no pueden estar vacio, que el numero de registros es el esperado, y que los ID han de ser los indicados…y todo esto solo pasa si este es el primer test.
Para el siguiente test, que hago en orden 2, podría hacerlo en cualquier sitio, ya que no tengo en cuenta ni el numero de registros, ni los IDs leídos….
El resto de test, los puedo hacer en cualquier orden, aunque he seguido repartiendo números. Por ejemplo, los de leer un registro, serán
Siendo el 20 para lectura correcta, y compruebo que obtengo el registro que cargue con la inicialización con el numero 16
El test 21, intenta acceder a un registro que no existe, y espera el error. muy semejante a lo que hacíamos en el testSpring, pero esta vez, no interferimos con cineService, y damos un número erróneo, para que el error sea real.
Luego, empezamos con la serie de POST, el primero, correcto
En la linea 172 enviamos un JSON correcto, y esperamos el «Registro Salvado», pero, para poder comprobar que la grabación se realiza podríamos utilizar la técnica del GET, pero como nuestra API no devuelve el ID asignado, lo que hacemos es un conteo de registros previo (línea 167) y después comprobamos que tenemos un registro más. (Línea 177)…
Los test 23,24 y 25 corresponden a la detección de errores, por lo que enviamos un JSON con un error, y esperamos el mensaje.
Para probar el PUT correcto, intentamos actualizar un registro existente, en linea 224, y posteriormente, lo leemos para ver que los cambios se han hecho correctos
La prueba de PUT erróneo, la hacemos creando en memoria un registro de cine inexistente, y pidiendo que nos lo actualice.
Para el DELETE correcto, damos orden de borrar un registro que se creó durante la inicialización (10), y, a continuación, esperamos recibir un error al leerlo, ya que no deberia existir.
El DELETE erróneo, ya es sencillo, damos la orden de borrar un registro que sabemos no se cargó (999999), y esperamos el error
Y, tenemos pendiente el comprobar el error de que no hay registros en un leerTodo, y en leerDireccion, pero….para eso, hemos de borrar el contenido de la BBDD; como sabemos lo que contiene, podemos hacer
SAbemos que el 10 lo hemos borrado (estamos haciendo el test en orden), y hemos creado uno, que tendrá como id el 1, damos las ordenes de borrado en 290 y 294, y si, es una forma, y hay otras….
Cuando ya hemos borrado todo, podemos dar la orden de lectura (linea297), y esperar el error
Y en el Test 910, la base de datos, ya esta vacia, por lo que nos basta dar la orden y esperar el error
Conclusión
Supongo que habéis visto que realizar test, ni siquiera los de integración, es demasiado dificil, y, lo que es más importante, mientras los preparas, muchas veces te das cuenta de puntos que has dejado débiles para produccion, y merecen ser modificados. Además, dentro de varios meses, cuando os pidan modificar la aplicación, descubrireis la seguridad que da, el poder lanzar todos los test, y comprobar que todo sigue funcionando…si, hacerme caso….no somos tan buenos….
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.
