Pruebas de API REST

Hay dos maneras de fracasar con las pruebas de una API Spring Boot, y se parecen menos de lo que se cree.

La primera es no escribirlas. Nadie lo admite, todo el mundo lo practica durante un tiempo, y el síntoma es conocido: cada modificación se convierte en una negociación, porque nadie sabe qué va a romper.

La segunda es más insidiosa porque tiene apariencia de rigor. Todo está anotado con @SpringBootTest, cada prueba arranca el contexto completo, la suite tarda once minutos, el equipo deja de ejecutarla en local y la mitad de las pruebas comprueban que Spring sabe mapear una URL, algo que Spring ya garantiza. Se ha pagado el precio de las pruebas sin obtener su valor: una suite lenta que ya nadie ejecuta no protege de nada.

La dosis correcta sale de una pregunta sencilla, planteada prueba a prueba: ¿qué código, escrito por mí, protege esta prueba? Si la respuesta es «la lógica de cálculo de la fecha de devolución», basta una prueba unitaria de unos pocos milisegundos. Si es «la serialización, la validación y el código de estado de mi controlador», un slice @WebMvcTest es la herramienta adecuada. Si es «mi consulta JPQL funciona en PostgreSQL», hace falta un PostgreSQL real, y Testcontainers lo proporciona.