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í
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
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
Descubre más desde Recursos para formacion
Suscríbete y recibe las últimas entradas en tu correo electrónico.
