Tests de integración con Spring Boot

Una suite de tests de Spring pasa de cuarenta segundos a once minutos sin que se haya añadido una sola línea de lógica de negocio. La causa casi siempre es la misma: el contexto de la aplicación se reconstruye decenas de veces. Spring almacena el contexto en caché y lo reutiliza entre las clases de test, pero solo si la configuración solicitada es estrictamente idéntica. Una clase que añade un @MockBean, una propiedad @TestPropertySource o un perfil distinto obtiene una clave de caché diferente, y por tanto un contexto nuevo, es decir, entre tres y ocho segundos adicionales de arranque. Veinte variantes de configuración suponen veinte arranques.

La segunda trampa es simétrica: anotar todas las clases de test con @SpringBootTest por comodidad. Entonces se carga el contenedor completo (seguridad, planificador, clientes HTTP, escuchadores de mensajes) para probar una consulta SQL de quince líneas. El test es lento y falla por motivos que no guardan relación con lo que verifica: basta con que falte un bean de infraestructura en el entorno de test para que caiga una clase que ni siquiera lo utiliza. La competencia que hay que adquirir aquí consiste en cargar lo mínimo posible sin perder realismo, y en limitar el número de configuraciones distintas del proyecto.