¿Cómo pruebas un servicio de Spring que usa una base de datos y llama a otra API?

Prueba la lógica de dominio con JUnit puro y sin contexto de Spring, ya que la inyección por constructor lo vuelve trivial. Prueba la persistencia contra una base de datos real en un contenedor en vez de un sustituto en memoria, porque los dialectos difieren y las migraciones también hay que probarlas. Usa slices de test en vez de arrancar la aplicación entera para los tests de controlador o de repositorio, y sustituye la API externa a nivel HTTP para que tu código de cliente, los reintentos y el parseo se ejecuten de verdad.

La mayor parte de la lógica recibe tests unitarios normales sin framework alguno: la inyección por constructor significa que puedo instanciar la clase con dobles de prueba para sus colaboradores y corre en milisegundos. Para la persistencia uso una base de datos real del mismo motor y versión en un contenedor, con las migraciones aplicadas como parte del arranque del test, así la propia migración se verifica en cada ejecución. Una base de datos en memoria es más rápida pero miente sobre dialectos y restricciones, y he publicado una consulta que funcionaba en los tests y fallaba en producción por eso. Para la capa web uso un slice que carga solo el controlador y la serialización, no la aplicación entera, porque arrancarlo todo en cada test es lo que hace que las suites tarden veinte minutos. La API externa se sustituye a nivel HTTP con un servidor simulado, así que mi configuración de cliente, los timeouts, la lógica de reintentos y el mapeo JSON se ejercitan de verdad. Además reutilizo contenedores durante la ejecución y hago rollback de cada test en una transacción, lo que mantiene las cosas aisladas y paralelizables.