Enjoy A New Student Discount All 55,000 Courses on sale for Only $12.99

Ends in 05h 23m 49s

Preparando un test de Junit5, en SpringBoot -II

Después de ver como preparar un test de Junit para SpringBoot en los métodos Get y delete, en este artículo vamos a revisar como hacemos lo mismo para el metodo Post y Put y de paso el cineProjection, que es aquel caso en donde utilizabamos un DTO especifico para enviar informacion concreta al cliente

Preparando los datos

En este caso, deberemos perfilar mejor los datos, ya que debemos enviar los objetos previstos, y, para eso, deberemos estar continuamente comprobando el codigo de nuestro controlador, y los resultados verificados que da nuestro Postman

Os paso la imagen completa, hay atributos que ya habíamos utilizado, y otros que son nuevos, como los objetos CineDTO que se han creado con datos erróneos….

Tambien recordad que el método setup de linea 82 ya lo habiamos creado en el ejercicio anterior, por lo que ahora, solo deberemos completarlo con la creación de los atributos nuevos

Si no veis claro el porqué crear tanto campo, no os preocupeis: dejarlos sin crear, y cuando escribáis los test, veréis la necesidad.

Los test de POST

Si, he dicho «los» porque deberemos crear uno para ver que funciona con datos correctos, y uno por cada caso de datos erróneos que podamos declarar.

POST correcto

El primero, en donde comprobamos que funciona con los datos correctos, puede ser así

CineControllerTestSpring

En la linea 176 indicamos a mock lo que debe devolver cuando alguien haga un insert de cualquier objeto tipo Cine, y que es nuestro objeto cine, y, al hacer la llamada, es necesario que indiquemos lo que se envia en el body, que son los datos del cine a crear

Para definir los datos que enviamos en nuestro perform, utilizamos el método contentType para informar del tipo, y el content para enviar el body, como hacemos en las líneas 178 y 179, luego, solo deberemos comprobar lo que recibimos.

Vemos que en esa situación, nuestro controlador nos enviará CREATED con un mensaje

CineControler

Solo nos queda hacer la llamada y analizar la respuesta, y eso es lo que hacemos con las lineas 177 a 183 del módulo de test.

Post erróneos

Para las pruebas de error, vamos a tener en cuenta que el controlador realiza un @Valid cuando llegan los datos

Eso nos va a obligar a enviar objetos DTO que contengan los errores que queremos probar. Cuando lleguen al controlador, fallará en la misma entrada, por culpa del @Valid, por lo que no nos debemos preocupar por nada más, ya que ha de generar una excepción, y ha de ir a parar al controllerAdvice…

En este caso, podemos trabajar directamente con objetos cineDTO porque no necesitamos simular nada (no llegará a realizar la llamada!.

Entonces, para probar la detección de nombre vacío, utilizo el objeto cineErrorNombre

Para verificar que se controle el error de calle vacía, utilizamos cineErrorCalle

y para comprobar que se esta filtrando la capacidad, nos queda cineErrorCapacidad. aunque en este caso, he decidido no comprobar el mensaje, y me basta con verificar que se ha dado un error en el campo afectado…

Testeando el PUT

Para el PUT deberíamos volver a verificar todas las comprobaciones del POST, aunque os lo dejo a vosotros, y solo vamos a ver el caso de ok, el error porque no existe el registro a modificar, y el error por otros motivos…

Comprobamos el PUT correcto

Para preparar el test, debemos acordarnos de revisar el servicio ya que allí hacemos un acceso a base de datos, que deberemos falsear

De momento, para verificar el test de put correcto, nos limitamos a ignorar todo lo que iba a hacer nuestro servicio y hacemos

Como hemos dicho que nuestro servicio iba a dar correcto, todo va bien

Comprobando el PUT erróneo

Realmente, a nivel de controlador, solo debemos recibir un true/false desde el servicio para validar la operación, aunque a nivel de servicio, se puede dar error por dos motivos, uno es que el registro a modificar no exista, el otro a algun error de acceso a datos.

Vamos a probar las dos causas, aunque casi quedan fuera de lugar, pero, …ya se sabe… al escribir para formación….

El test básico, será

Como veis, simulo totalmente el servicio, y digo que devolverá false; con eso basta

Para el otro, debo falsear la respuesta de findById, que devolverá un objeto vacio, y como consecuencia, el servicio saldrá por exception, y no hará nada mas

Podéis revisar el servicio, lo teneis en GitHub

Conclusión

Con esto, tenemos probado el controlador, aunque hay bastantes pruebas mas que podriamos escribir…cuantas mas pruebas, mas seguridad de la estabilidad…..

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

Deja un comentario

/*Si te ha gustado el artículo
no dudes en compartirlo*/

Facebook
Twitter
LinkedIn

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies

Ver mi IP

Ver ip de mi máquina
tipo valor
Ip: 35.172.230.21
Proxy: 35.172.230.21
Remote host: ec2-35-172-230-21.compute-1.amazonaws.com
Remote port: 49388
** 35.172.230.21, 172.70.39.31