<aside>

Contenido

1. Introducción
2. Stack tecnológico
3. Arquitectura de Software
4. Esquema / Diseño de Base de Datos
5. Integración RabbitMQ
6. ms-clientes → Microservicio (Cliente, Persona)
7. ms-cuentas → Microservicio (Cuenta, Movimientos)
8. Comunicación entre microservicios
9. Seguridad
10. Pruebas unitarias
11. Pruebas de integración
12. Buenas prácticas de desarrollo
13. Documentación API
14. Despliegue en Docker
15. CI/CD → AWS EC2
16. Probar solución

</aside>

<aside>

Pruebas de Integración (F6)

Las pruebas de integración validan el flujo completo de la API: desde la petición HTTP hasta la base de datos y viceversa. A differencia de las unitarias, aquí se levanta todo el contexto de Spring Boot con infraestructura real.

Tecnologías utilizadas:

Testcontainers 2.0: Levanta contenedores Docker reales de PostgreSQL y RabbitMQ exclusivos para el test. Se crean antes de los tests y se destruyen al terminar. No depende del ambiente local.

MockMvc: Simula peticiones HTTP al controller sin necesidad de un servidor real.

@DynamicPropertySource: Inyecta dinámicamente las URLs de los contenedores en la configuración de Spring.

¿Qué hace antes de los tests?

1. Crea un contenedor Docker de PostgreSQL (base de datos vacía).
2. Crea un contenedor Docker de RabbitMQ.
3. Levanta la aplicación Spring Boot conectada a esos contenedores.
4. Hibernate crea las tablas automáticamente.

Tests implementados (en orden):

1. POST /clientes: Crear cliente exitosamente → espera 201 Created.
2. POST /clientes: Identificación duplicada → espera 409 Conflict.
3. POST /clientes: Request sin campos obligatorios → espera 400 Bad Request con errores de validación.
4. GET /clientes: Listar todos → espera 200 con al menos 1 cliente.
5. GET /clientes/{id}: Obtener por ID → espera 200 con datos correctos.
6. GET /clientes/9999: ID inexistente → espera 404 Not Found.
7. PUT /clientes/{id}: Actualizar cliente → espera 200 con nombre cambiado.
8. PATCH /clientes/{id}: Actualizar solo teléfono → espera 200, teléfono cambiado, nombre intacto.
9. DELETE /clientes/{id}: Soft delete → espera 204, después GET confirma estado: false.
10. POST /clientes: Género inválido → espera 400 con mensaje "solo acepta los valores: [MASCULINO, FEMENINO, OTRO]". </aside>