SpringBoot
Tutorial SpringBoot: Testing controladores Spring MVC con Thymeleaf
Utiliza MockMvc para realizar testing de integración de controladores MVC con modelo y vista en Spring Boot.
Aprende SpringBoot GRATIS y certifícateTest 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 controladorControladorUsuario
. - 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 conwhen
ythenReturn
. - 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 alusuarioMock
.
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áticamenteMockMvc
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 elMvcResult
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.
Ejercicios de esta lección Testing controladores Spring MVC con Thymeleaf
Evalúa tus conocimientos de esta lección Testing controladores Spring MVC con Thymeleaf con nuestros retos de programación de tipo Test, Puzzle, Código y Proyecto con VSCode, guiados por IA.
API Query By Example (QBE)
Identificadores y relaciones JPA
Borrar datos de base de datos
Web y Test Starters
Métodos find en repositorios
Controladores Spring MVC
Inserción de datos
CRUD Customers Spring MVC + Spring Data JPA
Backend API REST con Spring Boot
Controladores Spring REST
Uso de Spring con Thymeleaf
API Specification
Registro de usuarios
Crear entidades JPA
Asociaciones en JPA
Asociaciones de entidades JPA
Integración con Vue
Consultas JPQL
Open API y cómo agregarlo en Spring Boot
Uso de Controladores REST
Repositorios reactivos
Inyección de dependencias
Introducción a Spring Boot
CRUD y JPA Repository
Inyección de dependencias
Vista en Spring MVC con Thymeleaf
Servicios en Spring
Operadores Reactivos
Configuración de Vue
Entidades JPA
Integración con Angular
API Specification
API Query By Example (QBE)
Controladores MVC
Anotaciones y mapeo en JPA
Consultas JPQL con @Query en Spring Data JPA
Repositorios Spring Data
Inyección de dependencias
Data JPA y Mail Starters
Configuración de Angular
Controladores Spring REST
Configuración de Controladores MVC
Consultas JPQL con @Query en Spring Data JPA
Actualizar datos de base de datos
Verificar token JWT en peticiones
Login de usuarios
Integración con React
Configuración de React
Todas las lecciones de SpringBoot
Accede a todas las lecciones de SpringBoot y aprende con ejemplos prácticos de código y ejercicios de programación con IDE web sin instalar nada.
Introducción A Spring Boot
Introducción Y Entorno
Spring Boot Starters
Introducción Y Entorno
Inyección De Dependencias
Introducción Y Entorno
Controladores Spring Mvc
Spring Web
Vista En Spring Mvc Con Thymeleaf
Spring Web
Controladores Spring Rest
Spring Web
Open Api Y Cómo Agregarlo En Spring Boot
Spring Web
Servicios En Spring
Spring Web
Clientes Resttemplate Y Restclient
Spring Web
Rxjava En Spring Web
Spring Web
Crear Entidades Jpa
Persistencia Spring Data
Asociaciones De Entidades Jpa
Persistencia Spring Data
Repositorios Spring Data
Persistencia Spring Data
Métodos Find En Repositorios
Persistencia Spring Data
Inserción De Datos
Persistencia Spring Data
Actualizar Datos De Base De Datos
Persistencia Spring Data
Borrar Datos De Base De Datos
Persistencia Spring Data
Consultas Jpql Con @Query En Spring Data Jpa
Persistencia Spring Data
Api Query By Example (Qbe)
Persistencia Spring Data
Api Specification
Persistencia Spring Data
Repositorios Reactivos
Persistencia Spring Data
Introducción E Instalación De Apache Kafka
Mensajería Asíncrona
Crear Proyecto Con Apache Kafka
Mensajería Asíncrona
Creación De Producers
Mensajería Asíncrona
Creación De Consumers
Mensajería Asíncrona
Kafka Streams En Spring Boot
Mensajería Asíncrona
Introducción A Spring Webflux
Reactividad Webflux
Spring Data R2dbc
Reactividad Webflux
Controlador Rest Reactivo Basado En Anotaciones
Reactividad Webflux
Controlador Rest Reactivo Funcional
Reactividad Webflux
Operadores Reactivos Básicos
Reactividad Webflux
Operadores Reactivos Avanzados
Reactividad Webflux
Cliente Reactivo Webclient
Reactividad Webflux
Introducción A Spring Security
Seguridad Con Spring Security
Seguridad Basada En Formulario En Mvc Con Thymeleaf
Seguridad Con Spring Security
Registro De Usuarios
Seguridad Con Spring Security
Login De Usuarios
Seguridad Con Spring Security
Verificar Token Jwt En Peticiones
Seguridad Con Spring Security
Seguridad Jwt En Api Rest Spring Web
Seguridad Con Spring Security
Seguridad Jwt En Api Rest Reactiva Spring Webflux
Seguridad Con Spring Security
Autenticación Y Autorización Con Anotaciones
Seguridad Con Spring Security
Testing Unitario De Componentes Y Servicios
Testing Con Spring Test
Testing De Repositorios Spring Data Jpa
Testing Con Spring Test
Testing Controladores Spring Mvc Con Thymeleaf
Testing Con Spring Test
Testing Controladores Rest Con Json
Testing Con Spring Test
Testing De Aplicaciones Reactivas Webflux
Testing Con Spring Test
Testing De Seguridad Spring Security
Testing Con Spring Test
Testing Con Apache Kafka
Testing Con Spring Test
Integración Con Angular
Integración Frontend
Integración Con React
Integración Frontend
Integración Con Vue
Integración Frontend
En esta lección
Objetivos de aprendizaje de esta lección
- Aprender a ejecutar pruebas de controladores MVC en Spring Boot
- Uso de MockMvc
- Creación de pruebas de integración parcial
- Creación de pruebas de integración completa