Tutorial SpringBoot: Testing controladores Spring MVC con Thymeleaf

Test de integración parcial de controlador MVC

Para realizar tests de integración parcial en controladores MVC que utilizan vistas Thymeleaf, se emplea la anotación @WebMvcTest junto con el objeto MockMvc. Esta combinación permite probar el comportamiento del controlador en un contexto web simulado, sin cargar todo el contexto de la aplicación.

La anotación @WebMvcTest configura el entorno para probar únicamente componentes web, como los controladores, filtros y configuraciones MVC. Además, es posible mockear las dependencias del controlador, como los servicios, para aislar y centrarse en la lógica de la capa web.

A continuación, se presenta un ejemplo de cómo implementar un test de integración parcial para un controlador MVC:

@WebMvcTest(ControladorUsuario.class)
class ControladorUsuarioTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private ServicioUsuario servicioUsuario;

    @Test
    void testMostrarUsuario() throws Exception {
        Usuario usuarioMock = new Usuario(1L, "Juan Pérez", "juan.perez@example.com");
        when(servicioUsuario.obtenerUsuarioPorId(1L)).thenReturn(Optional.of(usuarioMock));

        mockMvc.perform(get("/usuarios/1"))
                .andExpect(status().isOk())
                .andExpect(view().name("detalleUsuario"))
                .andExpect(model().attributeExists("usuario"))
                .andExpect(model().attribute("usuario", usuarioMock));
    }
}

En este test:

• Se utiliza @WebMvcTest para indicar que se probará el controlador ControladorUsuario.
• Se inyecta MockMvc para simular peticiones HTTP al controlador.
• Se marca ServicioUsuario con @MockBean para simular su comportamiento y evitar llamar a la implementación real.
• Se define un usuario de prueba usuarioMock y se especifica el comportamiento esperado del servicio con when y thenReturn.
• Se realiza una petición GET a la URL /usuarios/1 y se verifican varias condiciones:
• Que el estado de la respuesta sea 200 OK.
• Que se utilice la vista detalleUsuario.
• Que el modelo contenga un atributo usuario.
• Que el atributo usuario en el modelo corresponda al usuarioMock.

Es importante destacar que MockMvc permite realizar peticiones HTTP simuladas y validar la respuesta del controlador, incluyendo la vista renderizada y el modelo asociado. De esta forma, se puede asegurar que el controlador interactúa correctamente con las vistas Thymeleaf.

Otro aspecto relevante es el uso de @MockBean. Esta anotación permite reemplazar beans en el contexto de pruebas por mocks de Mockito. Así, al mockear ServicioUsuario, se evita acceder a la capa de datos y se tiene control total sobre las respuestas que proporciona durante el test.

Para ampliar el test anterior y verificar cómo el controlador maneja un usuario no encontrado, se puede agregar otro método de prueba:

@Test
void testMostrarUsuarioNoEncontrado() throws Exception {
    when(servicioUsuario.obtenerUsuarioPorId(99L)).thenReturn(Optional.empty());

    mockMvc.perform(get("/usuarios/99"))
            .andExpect(status().isNotFound())
            .andExpect(view().name("error/404"));
}

En este caso:

• Se simula que el servicio devuelve Optional.empty(), indicando que el usuario no existe.
• Se espera que el controlador responda con un estado 404 Not Found y que muestre la vista de error correspondiente.

Es fundamental configurar correctamente el mapeo de excepciones en el controlador o en una clase controller advice para que el test pase exitosamente.

Además de verificar el estado y la vista, también es posible comprobar el contenido generado por la vista Thymeleaf. Para ello, se puede utilizar el método andExpect(content().string(containsString("texto"))). Sin embargo, en tests de integración parcial, suele ser suficiente validar la vista y los atributos del modelo.

Al trabajar con @WebMvcTest, es posible personalizar el contexto de pruebas agregando configuraciones adicionales o iniciando sólo los componentes necesarios. Esto contribuye a que los tests sean más rápidos y enfocados.

El uso de @WebMvcTest y MockMvc junto con mocks de servicios permite realizar tests de integración parcial efectivos, asegurando que los controladores MVC funcionan correctamente en conjunto con las vistas Thymeleaf y el modelo.

Test de integración completa de controlador MVC

Para garantizar que todos los componentes de nuestra aplicación Spring Boot funcionan correctamente en conjunto, es esencial realizar tests de integración completa. Estos tests verifican la interacción entre el controlador, los servicios reales y las vistas Thymeleaf, asegurando que la aplicación se comporta como se espera en un entorno real.

La anotación @SpringBootTest se utiliza para cargar el contexto completo de la aplicación, incluyendo todos los beans y configuraciones. Al combinarla con @AutoConfigureMockMvc, podemos inyectar una instancia de MockMvc que nos permite simular peticiones HTTP sin necesidad de iniciar un servidor web real.

A continuación, se muestra un ejemplo de cómo implementar un test de integración completa para un controlador MVC que utiliza servicios reales:

@SpringBootTest
@AutoConfigureMockMvc
class ProductoControladorTest {

    @Autowired
    private MockMvc mockMvc;

    @Autowired
    private ProductoServicio productoServicio;

    @Test
    void testListarProductos() throws Exception {
        mockMvc.perform(get("/productos"))
                .andExpect(status().isOk())
                .andExpect(view().name("listaProductos"))
                .andExpect(model().attributeExists("productos"))
                .andExpect(model().attribute("productos", hasSize(greaterThan(0))));
    }
}

En este test:

• Se utiliza @SpringBootTest para cargar todo el contexto de la aplicación.
• La anotación @AutoConfigureMockMvc configura automáticamente MockMvc para su inyección.
• No se mockea el servicio ProductoServicio; se utiliza la implementación real.
• Se realiza una petición GET a la ruta /productos y se verifica que:
• El estado de la respuesta es 200 OK.
• La vista utilizada es listaProductos.
• El modelo contiene el atributo productos.
• La lista de productos tiene al menos un elemento.

Este enfoque permite probar la aplicación en condiciones más cercanas a la producción, ya que se incluyen todos los componentes reales. Sin embargo, es importante controlar el estado de la base de datos para evitar dependencias indeseadas entre tests.

Para asegurar que los tests son reproducibles y no dependen del estado previo, es habitual usar una base de datos en memoria y limpiar los datos antes de cada prueba. Podemos hacer esto utilizando las anotaciones @TestMethodOrder y @Transactional:

@SpringBootTest
@AutoConfigureMockMvc
@Transactional
class ProductoControladorTest {

    @Autowired
    private MockMvc mockMvc;

    @Autowired
    private ProductoRepositorio productoRepositorio;

    @Test
    void testCrearProducto() throws Exception {
        mockMvc.perform(post("/productos")
                .param("nombre", "Nuevo Producto")
                .param("precio", "99.99"))
                .andExpect(status().is3xxRedirection())
                .andExpect(view().name("redirect:/productos"));

        assertTrue(productoRepositorio.existsByNombre("Nuevo Producto"));
    }
}

En este caso:

• La anotación @Transactional asegura que cada test se ejecuta en una transacción aislada, que se revierte al finalizar.
• Se realiza una petición POST para crear un nuevo producto.
• Se verifica que la respuesta es una redirección, indicando que el producto se creó correctamente.
• Se comprueba que el producto existe en la base de datos utilizando el repositorio real.

Al utilizar los servicios y repositorios reales, nuestros tests validan no sólo el controlador, sino también la lógica de negocio y el acceso a datos. Esto ayuda a detectar problemas como configuraciones incorrectas o errores en las consultas SQL.

Es posible que en algunos casos necesitemos redefinir ciertas propiedades para las pruebas. Por ejemplo, si queremos utilizar un perfil de configuración específico, podemos hacerlo con la anotación @ActiveProfiles:

@SpringBootTest
@AutoConfigureMockMvc
@ActiveProfiles("test")
class ProductoControladorTest {
    // ...
}

Al activar el perfil test, podemos definir propiedades específicas en application-test.properties que solo se aplicarán durante los tests. Esto es útil para configurar una base de datos en memoria o ajustar otras configuraciones necesarias.

Para ejecutar pruebas más complejas, como verificar la vista renderizada, podemos utilizar el atributo content de la respuesta:

@Test
void testDetalleProducto() throws Exception {
    Producto producto = productoRepositorio.save(new Producto("Producto Detalle", 49.99));

    mockMvc.perform(get("/productos/" + producto.getId()))
            .andExpect(status().isOk())
            .andExpect(view().name("detalleProducto"))
            .andExpect(model().attributeExists("producto"))
            .andExpect(xpath("/html/body/h1").string("Producto Detalle"));
}

En este ejemplo:

• Se guarda un producto en la base de datos para asegurar que existe.
• Se realiza una petición GET al detalle del producto.
• Se verifica que la vista utilizada es detalleProducto.
• Se comprueba que el modelo contiene el atributo producto.
• Se utiliza XPath para verificar que el título de la página contiene el nombre del producto.

La posibilidad de inspeccionar el contenido de la vista renderizada nos permite validar que Thymeleaf está procesando correctamente las plantillas y mostrando la información adecuada.

Además, si nuestra aplicación utiliza internacionalización, podemos simular peticiones con diferentes locales:

@Test
void testPaginaEnEspañol() throws Exception {
    mockMvc.perform(get("/productos").locale(new Locale("es")))
            .andExpect(status().isOk())
            .andExpect(view().name("listaProductos"))
            .andExpect(model().attributeExists("productos"))
            .andExpect(content().string(containsString("Lista de Productos")));
}

Aquí, se especifica el locale español en la petición, y se verifica que la vista contiene el texto en español correspondiente.

Es importante destacar que al realizar tests de integración completa, debemos ser conscientes del rendimiento. Estos tests suelen ser más lentos que los tests unitarios o de integración parcial, ya que implican cargar todo el contexto y posiblemente interactuar con la base de datos. Por ello, es recomendable enfocarse en los escenarios críticos y mantener un equilibrio entre cobertura y eficiencia.

Para concluir, los tests de integración completa con @SpringBootTest y @AutoConfigureMockMvc son una herramienta poderosa para validar el comportamiento integral de nuestra aplicación. Al utilizar servicios reales y verificar la interacción entre los diferentes componentes, podemos tener una alta confianza en la calidad de nuestro código y en el correcto funcionamiento de nuestras funcionalidades.

Explicación de todos los métodos de MockMvc

El objeto MockMvc es fundamental para realizar pruebas exhaustivas de controladores MVC en aplicaciones Spring Boot. Este objeto permite simular peticiones HTTP de forma controlada y verificar las respuestas generadas por los controladores, incluyendo vistas Thymeleaf y modelos.

Para utilizar MockMvc, es esencial comprender los métodos que proporciona. A continuación, se detallan los principales métodos y cómo utilizarlos eficazmente en las pruebas.

1. Método perform

El método perform es la entrada principal para ejecutar una petición HTTP simulada. Recibe como parámetro una instancia de MockHttpServletRequestBuilder, que se obtiene a través de los métodos estáticos de la clase MockMvcRequestBuilders.

Ejemplo:

mockMvc.perform(get("/usuarios/1"));

En este ejemplo, se está realizando una petición GET a la ruta /usuarios/1. La palabra clave aquí es perform, que ejecuta la petición y devuelve un objeto ResultActions para continuar con las verificaciones.

2. Clase MockMvcRequestBuilders

La clase MockMvcRequestBuilders proporciona métodos estáticos para construir peticiones HTTP de diversos tipos. Los métodos más comunes son:

• get(String urlTemplate, Object... uriVars)
• post(String urlTemplate, Object... uriVars)
• put(String urlTemplate, Object... uriVars)
• delete(String urlTemplate, Object... uriVars)
• patch(String urlTemplate, Object... uriVars)
• multipart(String urlTemplate, Object... uriVars) para peticiones de carga de archivos.

Por ejemplo, para realizar una petición POST con parámetros:

mockMvc.perform(post("/usuarios")
    .param("nombre", "María Gómez")
    .param("email", "maria.gomez@example.com"));

Aquí, el método post construye una petición POST, y el método param añade parámetros al cuerpo de la petición.

3. Métodos de configuración de la petición

Los MockHttpServletRequestBuilder permiten configurar detalles adicionales de la petición:

• content(String content) para establecer el cuerpo de la petición.
• contentType(MediaType mediaType) para indicar el tipo de contenido.
• accept(MediaType... mediaTypes) para especificar los tipos de contenido aceptables en la respuesta.
• header(String name, Object... values) para incluir encabezados personalizados.
• cookie(Cookie... cookies) para añadir cookies a la petición.
• locale(Locale locale) para establecer la localización.

Ejemplo de configuración de contenido JSON:

String jsonContent = "{ \"nombre\": \"Luis Pérez\", \"email\": \"luis.perez@example.com\" }";

mockMvc.perform(post("/api/usuarios")
    .content(jsonContent)
    .contentType(MediaType.APPLICATION_JSON)
    .accept(MediaType.APPLICATION_JSON));

En este caso, se utilizan los métodos content y contentType para configurar el cuerpo y el tipo de contenido de la petición.

4. Interfaz ResultActions

Tras ejecutar perform, se obtiene un objeto ResultActions, que permite encadenar métodos para verificar y documentar la respuesta del controlador.

• andExpect(ResultMatcher matcher) para definir expectativas sobre la respuesta.
• andDo(ResultHandler handler) para realizar acciones adicionales, como imprimir detalles.
• andReturn() para obtener el MvcResult de la ejecución.

Por ejemplo:

mockMvc.perform(get("/usuarios/1"))
    .andExpect(status().isOk())
    .andExpect(view().name("detalleUsuario"))
    .andExpect(model().attributeExists("usuario"));

Aquí, se están verificando el estado, la vista y los atributos del modelo mediante el método andExpect.

5. Clase ResultMatchers

ResultMatchers proporciona métodos estáticos para crear verificadores (ResultMatcher). Algunos de los más utilizados son:

status(): Verifica el código de estado HTTP de la respuesta.

Ejemplos:

• status().isOk()
• status().isNotFound()
• status().is3xxRedirection()

view(): Comprueba el nombre de la vista devuelta por el controlador.

Ejemplo:

• view().name("listaUsuarios")

model(): Verifica la existencia y los valores de los atributos en el modelo.

Ejemplos:

• model().attributeExists("usuario")
• model().attribute("usuario", hasProperty("nombre", is("Ana López")))

redirectedUrl(String expectedUrl): Verifica la URL de redirección.

Ejemplo:

• redirectedUrl("/usuarios")

flash(): Comprueba los atributos flash en una redirección.

Ejemplo:

• flash().attribute("mensaje", "Usuario creado con éxito")

content(): Permite verificar el contenido de la respuesta.

Ejemplos:

• content().string(containsString("Bienvenido"))
• content().contentType(MediaType.TEXT_HTML)

cookie(): Verifica las cookies en la respuesta.

Ejemplo:

• cookie().exists("sessionId")

La palabra clave aquí es ResultMatchers, que centraliza los métodos para configurar las expectativas sobre la respuesta.

6. Métodos de ResultActions para acciones adicionales

El método andDo permite realizar acciones adicionales con el resultado de la petición. Es útil para depuración y registro.

Por ejemplo, para imprimir la respuesta:

mockMvc.perform(get("/usuarios"))
    .andDo(print())
    .andExpect(status().isOk());

El método print() muestra detalles de la petición y la respuesta en la salida estándar, facilitando el análisis durante las pruebas.

7. Accediendo al resultado con andReturn

Si es necesario realizar verificaciones más complejas o acceder al cuerpo de la respuesta, se puede utilizar andReturn() para obtener un MvcResult.

Ejemplo:

MvcResult result = mockMvc.perform(get("/usuarios"))
    .andExpect(status().isOk())
    .andReturn();

String contenido = result.getResponse().getContentAsString();

Con el objeto MvcResult, es posible acceder a la respuesta completa y analizar detalles específicos. La palabra clave es andReturn, que proporciona acceso directo al resultado.

8. Construyendo peticiones con contenido complejo

Para peticiones que requieren enviar objetos complejos, es común convertirlos a formato JSON. Utilizando bibliotecas como Jackson, se puede serializar el objeto y enviarlo en el cuerpo de la petición.

Ejemplo:

Usuario nuevoUsuario = new Usuario("Laura Sánchez", "laura.sanchez@example.com");
String jsonUsuario = objectMapper.writeValueAsString(nuevoUsuario);

mockMvc.perform(post("/api/usuarios")
    .content(jsonUsuario)
    .contentType(MediaType.APPLICATION_JSON))
    .andExpect(status().isCreated());

Aquí, content y contentType se utilizan para enviar el objeto serializado en la petición.

9. Verificando excepciones manejadas por el controlador

Es posible probar cómo el controlador maneja excepciones y devuelve respuestas adecuadas.

Ejemplo:

mockMvc.perform(get("/usuarios/99"))
    .andExpect(status().isNotFound())
    .andExpect(view().name("error/404"));

En este caso, se espera que el controlador devuelva un estado 404 y una vista de error específica cuando el usuario no exista.

10. Uso de param y header para modificar la petición

Los métodos param y header permiten añadir parámetros y encabezados a la petición.

Ejemplo con parámetros de consulta:

mockMvc.perform(get("/usuarios")
    .param("pagina", "1")
    .param("tamaño", "20"))
    .andExpect(status().isOk());

Ejemplo con encabezados personalizados:

mockMvc.perform(get("/usuarios")
    .header("User-Agent", "Mozilla/5.0"))
    .andExpect(status().isOk());

La capacidad de añadir parámetros y encabezados permite simular diversas condiciones en las pruebas.

11. Verificación de redirecciones

Para comprobar que el controlador redirige correctamente, se utilizan los métodos status().is3xxRedirection() y redirectedUrl().

Ejemplo:

mockMvc.perform(post("/usuarios")
    .param("nombre", "Carlos Díaz")
    .param("email", "carlos.diaz@example.com"))
    .andExpect(status().is3xxRedirection())
    .andExpect(redirectedUrl("/usuarios"));

Aquí, se verifica que tras crear un usuario, el controlador redirige a la lista de usuarios.

12. Comprobando el contenido de la vista renderizada

Para validar partes específicas del contenido HTML generado, se puede utilizar content().string() junto con métodos de comparación o expresiones XPath.

Ejemplo con containsString:

mockMvc.perform(get("/usuarios"))
    .andExpect(status().isOk())
    .andExpect(content().string(containsString("Lista de Usuarios")));

Ejemplo con XPath:

mockMvc.perform(get("/usuarios/1"))
    .andExpect(status().isOk())
    .andExpect(xpath("//h1").string("Detalle de Usuario"));

Estos métodos permiten asegurarse de que la vista contiene elementos específicos, validando así la correcta integración de Thymeleaf.

13. Uso de sessionAttr y flashAttr

Para pruebas que involucran atributos de sesión o flash, se pueden utilizar sessionAttr y flashAttr para establecerlos en la petición.

Ejemplo:

mockMvc.perform(post("/login")
    .param("usuario", "admin")
    .param("contraseña", "12345")
    .sessionAttr("captcha", "abcde"))
    .andExpect(status().isOk());

Para verificar atributos flash en la respuesta:

mockMvc.perform(post("/usuarios")
    .param("nombre", "")
    .param("email", ""))
    .andExpect(status().is3xxRedirection())
    .andExpect(flash().attributeExists("errorMensaje"));

La manipulación de atributos de sesión y flash es esencial cuando se prueban flujos de autenticación o manejo de mensajes entre redirecciones.

14. Configurando peticiones multipart

Para pruebas que involucran carga de archivos, se utiliza multipart para construir la petición.

Ejemplo:

MockMultipartFile archivo = new MockMultipartFile("archivo", "test.txt", "text/plain", "Contenido de prueba".getBytes());

mockMvc.perform(multipart("/upload")
    .file(archivo))
    .andExpect(status().isOk());

El uso de multipart y MockMultipartFile facilita la simulación de peticiones con archivos adjuntos.

15. Personalización avanzada con ResultHandler

En situaciones en las que se requiere un manejo personalizado del resultado, se puede implementar un ResultHandler y utilizarlo con andDo.

Ejemplo:

mockMvc.perform(get("/usuarios"))
    .andDo(result -> {
        MockHttpServletResponse response = result.getResponse();
        String contenido = response.getContentAsString();
        // Realizar operaciones personalizadas con el contenido
    })
    .andExpect(status().isOk());

Esta flexibilidad permite realizar verificaciones o acciones que no están cubiertas por los métodos estándar.

16. Verificación de tiempos y retardos

Aunque no es común, es posible verificar tiempos de respuesta o simular retardos si el controlador lo soporta.

Ejemplo:

mockMvc.perform(get("/usuarios/demorado"))
    .andExpect(status().isOk())
    .andExpect(request().asyncStarted())
    .andExpect(request().asyncResult(is("Completado")));

Aquí, se comprueba que la petición se procesa de forma asíncrona y se obtiene el resultado esperado.

17. Utilizando cookie para verificar cookies en la respuesta

Es posible verificar que el controlador establece cookies adecuadamente.

Ejemplo:

mockMvc.perform(post("/login")
    .param("usuario", "admin")
    .param("contraseña", "12345"))
    .andExpect(status().isOk())
    .andExpect(cookie().exists("JSESSIONID"));

El método cookie proporciona diversas verificaciones, como existencia, valores y propiedades de las cookies.

18. Comprobando encabezados en la respuesta

Para verificar que ciertos encabezados están presentes en la respuesta, se utiliza header() en los ResultMatchers.

Ejemplo:

mockMvc.perform(get("/descarga"))
    .andExpect(status().isOk())
    .andExpect(header().exists("Content-Disposition"))
    .andExpect(header().string("Content-Disposition", "attachment; filename=\"reporte.pdf\""));

Esto es útil cuando el controlador debe proporcionar archivos para descarga o establecer encabezados específicos.

19. Verificación de métodos HTTP no soportados

Es importante probar cómo el controlador responde a métodos HTTP inapropiados.

Ejemplo:

mockMvc.perform(patch("/usuarios/1"))
    .andExpect(status().isMethodNotAllowed());

Al utilizar el método patch, se comprueba que el controlador devuelve el código de estado adecuado al no soportar ese método.

20. Encadenamiento de expectativas

Los métodos andExpect pueden encadenarse para crear verificaciones complejas en una sola sentencia.

Ejemplo:

mockMvc.perform(get("/usuarios"))
    .andExpect(status().isOk())
    .andExpect(view().name("listaUsuarios"))
    .andExpect(model().attribute("usuarios", hasSize(greaterThan(0))))
    .andExpect(content().string(containsString("Lista de Usuarios")));

Este encadenamiento mejora la legibilidad y mantiene las pruebas concisas, destacando la capacidad de combinar múltiples verificaciones de manera fluida.