Preparando un test de Junit5, en SpringBoot -I

Vamos a utilizar lo que estuvimos escribiendo en el artículo anterior en que empezábamos nuestra presentación de Junit5, para preparar un verdadero test de un controlador de SpringBoot que gestiona el CRUD de una tabla, en modo de API.

Debido a la longitud de la explicación, sobre todo la version de video, he decidido partir este desarrollo en dos articulas, en este primero, veremos el test de las funciones de GET, y DELETE, dejando para el siguiente articulo, las funciones de PUT y POST.

Nuestras definiciones

Vamos a establecer todos los atributos que vamos a necesitar para realizar estos test, y serán

Lo primero que tengo que hacer es anotar la clase como @WebMvcTest y le indico que el controlador que voy a comprobar es CineController

El resto de información, ya se comento en el anterior artículo, lo mismo que el método anotado como @BeforeEach, y que, recordad, se ejecutará antes de cada test, y yo lo utilizo para recargar los atributos

Nota: Recordad que teneis el ejercicio completo en GitHub

Test de lectura correcta de un cine

Para probar que nuestro controlador se comporta correctamente al leer un registro, deberemos falsear la lectura del registro, y darle uno correcto como hicimos en el articulo anterior

Pero si solo hacemos esto, tendremos un problema; veamos el controlador:

En efecto, cuando le indiquemos que queremos leer el 1, Spring intentará hacer la validacion @CheckCineValidation, y como nuestra base de datos no existe, nos dara error, luego, tambien deberemos falsear esa lectura. Si me veo CheckCineValidator, compruebo que hace la validacion con un existById, con lo que se que deberé añadir un segundo mock.

El método quedará asi:

Damos la orden de ejecución con  mvc.perform(get(«/api/cine/1»)) que es lo mismo que escribiríamos en Postman para hacer la prueba.

Nota: Comentado teneis el codigo necesario para revisar la respuesta completa (andDo(.print())

No hace la lectura, pero recibe un registro de cine, y con los andExpect Comprueba que el valor de cada campo sea el esperado. Si vemos la operación en POSTMAN

Realmente el andReturn final solo lo necesitamos si vamos a trabajar con el result que generamos, si no es asi, como en esta caso, nos bastara con no igualar la operación a nada, y retirar al andReturn()

Test de lectura errónea de un cine

Esta prueba puede ser mu sencilla, vemos como se comporta en Postman

y revisamos nuestro controlador para ver que tenemos que simular

Pero, podemos observar que lo primero que hara es un @CheckCineValidation, y conocemos como falsearlo, por lo que solo deberemos escribir el método

y comprobamos que devuelve lo mismo que hizo en Postman: el status http ha de ser 422 y, esta vez debemos comprobar el mensaje que, en este caso, sabemos que es un Map, y sabemos el mensaje que ha de venir en el puesto «leerUno.id», y que ha de contener «no existe»

Os dejo a vosotros los detalles CORRECTOS como es trabajar con constantes tambien en los mensaje…. yo hare una revision….

Test de leer todos

Supongo que empezáis a ver como funciona, por lo que la comprobación de este método será mas sencilla. Nuestro método

Preparo una lista de cines solo con un cine y defino un mock para que cDao (el servicio) devuelva esa lista

A continuación, compruebo que en el primer elemento de la lista [0] tengo los datos previstos

Y para la prueba de error, solo tengo que hacer que entregue una lista vacia, y, a continuación, compruebo lo que me llega…..

Nota: Comentado tenéis como podeis leer lo que os entrega el andReturn()

Test de borrado correcto

Si habeis ido haciendo pruebas, a estas alturas deberíais prevenir lo que voy a contar, porque la prueba de borrado correcto, es de lo mas fácil.

Como el controlador utiliza un @CheckCineValidation, deberemos preparar la respuesta que nos interese para el existsById, que será true, y luego, tambien diremos que cuando se intente hacer un deleteById, tambien se conteste true

Luego, solo comprobar la respuesta…que la podeis obtener mirando el controlador, o haciendo una prueba en Postman

Test de borrado erróneo

La ultima de la serie, aunque supongo que todos ya la habeis escrito. Para que no se diga, os la muestro

Efectivamente, me aprovecho de de la validación de @CheckCineValidation para que devuelva false en cDao.existsById() y el resto, a comprobar lo de siempre

Conclusión

Os animo a que escribais este test y lo probeis. Como veis, es una evolución del que hicimos antes, pero este deberia ser el único de los dos que yo haria en un caso real; el del articulo anterior solo fue una introducción.

En el siguiente articulo, terminamos el test del controlador, haciendo los métodos que faltan.

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