<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 Unitarias (F5)

Las pruebas unitarias validan la lógica de negocio del Service de forma aislada, sin levantar Spring ni conectarse a base de datos. Se utiliza Mockito para simular (mockear) las dependencias: ClienteRepository, ClienteMapper, ClienteEventPublisher y PasswordEncoder.

Patrón utilizado: AAA (Arrange, Act, Assert) Cada test sigue esta estructura:

• Arrange: Se preparan los datos y se configuran los mocks (when(...).thenReturn(...)).
• Act: Se ejecuta el método del Service que se está probando.
• Assert: Se verifican los resultados con AssertJ (assertThat) y se compruebab que los mocks fueron invocados correctamente (verify).

Tests implementados:

Crear cliente:

• Debe crear un cliente exitosamente: verifica que se genera el clienteId, se hashea la contraseña, se guarda en BD y se publica el evento a RabbitMQ.
• Debe lanzar excepción si la identificación ya existe: verifica que retorna DuplicateResourceException y que nunca llama a save().

Obtener cliente:

• Debe obtener un cliente por ID: verifica que retorna los datos correctos del DTO.
• Debe lanzar excepción si el cliente no existe: verifica ResourceNotFoundException.
• Debe obtener todos los clientse: verifica que retorna la lista completa.

Actualizar cliente:

• Debe actualizar un cliente exitosamente: verifica que se actualizan los campos, se hashea la nueva contraseña y se publica evento.

Eliminar cliente (Soft Delete):

• Debe marcar el cliente como inactivo: verifica que estado cambia a false, que se llama a save() y que nunca se llama a delete().
• Debe lanzar excepción si el cliente no existe.

¿Por qué Mockito y no base de datos real?

Las pruebas unitarias deben ser rápidas (~1 segundo) y no depender de infraestructura externa. Mockito simula las dependencias para que solo se pruebe la lógica del Service. Las pruebas que necesitan infraestructura real son las de integración.

</aside>