Tests de API y de Carga: MockMvc, REST Assured, BDD y JMeter

@WebMvcTest(TareaController.class) crea un contexto de Spring reducido: el controlador indicado, los @ControllerAdvice, los convertidores de Jackson, la validación, los filtros y la seguridad web si está configurada. No crea servicios ni repositorios, así que los que necesite el controlador se aportan con @MockitoBean. Arranca en uno o dos segundos y cada test tarda milisegundos.

MockMvc ejecuta la petición por toda la pila de Spring MVC sin abrir un puerto: el DispatcherServlet resuelve la ruta, deserializa el cuerpo, valida, llama al controlador y serializa la respuesta. Con jsonPath compruebas campos concretos del JSON, y con header(), las cabeceras. Desde Spring Framework 6.2 existe también MockMvcTester, con aserciones al estilo AssertJ.

Qué probar aquí: códigos de estado, validación de la entrada, formato de los errores (ProblemDetail), cabeceras como Location, la serialización de fechas y enums, y las reglas de seguridad de cada endpoint. Qué no: la lógica de negocio (va en tests unitarios del servicio) ni el acceso a datos.

Con @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT), Spring arranca la aplicación completa con un servidor real en un puerto libre, que se inyecta con @LocalServerPort. REST Assured hace peticiones HTTP de verdad con una sintaxis given/when/then y valida estado, cabeceras y cuerpo con matchers de Hamcrest, o extrayendo la respuesta a un objeto.

Combinado con Testcontainers y @ServiceConnection, el test recorre todo el camino que recorrerá un cliente: filtros de seguridad, serialización real, servicio, transacciones y base de datos PostgreSQL. Detecta errores que ningún test aislado ve: una propiedad de configuración mal escrita, un filtro que bloquea la ruta, una columna que no acepta null.

Son tests caros (segundos cada uno), así que se reservan para los flujos críticos de punta a punta. Reutiliza el mismo contexto de Spring entre clases (con la misma configuración, Spring lo guarda en caché) y el mismo contenedor, y limpia los datos entre tests en lugar de reiniciar nada.

Gherkin es el lenguaje de los escenarios: un fichero .feature contiene una Característica con varios Escenario, y cada uno se escribe con pasos Dado (contexto), Cuando (acción) y Entonces (resultado), más Y y Pero para encadenar. Con # language: es en la primera línea, las palabras clave van en español, y un Esquema del escenario con una tabla de Ejemplos ejecuta el mismo escenario con varios datos.

Cada paso se conecta con un método Java anotado (@Dado, @Cuando, @Entonces) mediante Cucumber Expressions, donde {string} o {int} capturan parámetros. El estado entre pasos se guarda en los campos de la clase de pasos, que Cucumber crea de nuevo para cada escenario; con cucumber-spring, esa clase puede recibir beans de Spring.

Cucumber aporta valor cuando las personas de negocio leen o escriben los escenarios y estos sirven como criterios de aceptación vivos. Si solo los lee el equipo técnico, es una capa de indirección que JUnit con nombres claros y estructura given/when/then resuelve con menos coste.

Una prueba de carga responde a preguntas concretas: cuántas peticiones por segundo aguanta el servicio, qué latencia tienen el 95 % y el 99 % de las peticiones con esa carga, y qué recurso se agota primero. En JMeter, un plan (.jmx) tiene grupos de hilos (usuarios virtuales, rampa de subida y duración), samplers HTTP con las peticiones, extractores para encadenar datos (el id de la tarea creada) y aserciones sobre las respuestas.

El plan se diseña en la interfaz gráfica, pero se ejecuta siempre en modo no interactivo (-n), que consume mucho menos y genera un informe HTML con percentiles, rendimiento y errores a lo largo del tiempo. Gatling, k6 y Locust son alternativas que escriben los escenarios como código y encajan mejor en un repositorio y en el CI.

Para que los resultados signifiquen algo, la prueba se lanza contra un entorno con datos y recursos parecidos a producción, desde una máquina distinta a la del servicio, con una rampa de subida y mirando a la vez las métricas del servicio (CPU, memoria, pool de conexiones, GC). El objetivo no es un número aislado, sino encontrar el punto en que la latencia se dispara y entender por qué.

Cada tipo de test tiene un coste distinto y debe ejecutarse donde más aporta. En cada push o en el ordenador del desarrollador: unitarios y tests de slice (@WebMvcTest, y @DataJpaTest con Testcontainers si son rápidos), que deben terminar en pocos minutos. En cada pull request: además, los de integración completos con REST Assured. Antes de una release o cada noche: pruebas de carga y de extremo a extremo contra un entorno de preproducción.

Con Maven, la separación es natural: Surefire ejecuta en la fase test las clases *Test, y Failsafe ejecuta en integration-test y verify las clases *IT, asegurando que el entorno se limpia aunque fallen. Así ./mvnw test es rápido y ./mvnw verify lo ejecuta todo.

Un pipeline útil es rápido, fiable y explica sus fallos: los tests intermitentes se corrigen o se aíslan en el momento, no se reintentan hasta que pasan; los informes (JUnit, JaCoCo, el HTML de JMeter) se publican como artefactos; y un fallo de rendimiento por encima del umbral acordado bloquea la release igual que un test en rojo.