Credit Card - Module

Desarrollo de Software 2 - ISO-124

Grupo: A | Sección: D

Git Push Party:

Cristian Galeano Borbosa
Edwin Arias Martinez
Said Acosta Cepeda
Rodrigo Vergara
Catriel Pereira Torrez

26/11/2024
Indice

🏦 Módulo de Tarjetas de Crédito

Last edited by Catriel21 just now

¡Bienvenido a la wiki del proyecto de Tarjetas de Crédito! Este módulo forma parte de un sistema bancario y se enfoca en proporcionar funcionalidades
avanzadas para la gestión de tarjetas de crédito.

El proyecto sigue la arquitectura Onion, lo que facilita:

🔄 Separación de responsabilidades.
🧪 Mejora de la testabilidad.
📈 Estructura escalable y mantenible.
📚 Secciones Principales
Explora las distintas secciones de esta wiki para descubrir información detallada sobre el diseño, desarrollo y pruebas del módulo.

🏗️ Architectural Pattern
📝 User Stories
🎯 4P's
📄 Casos de Uso
🧩 Design Patterns
🌐 Epics
📝 Meeting Notes
🚀 Pipeline
💡 Prueba de Concepto
✅ Unit Test

💡 Sigue explorando para descubrir cómo estamos llevando este proyecto al éxito!
Architectural Pattern

🧅 Documentación de la Arquitectura Onion

Last edited by Edwin Arias 3 days ago

1. 🌟 Introducción a la Arquitectura Onion

La Arquitectura Onion es un patrón arquitectónico diseñado para mantener la lógica de negocio independiente de la infraestructura, facilitando la
testabilidad y la mantenibilidad. Este enfoque se basa en la separación de responsabilidades mediante capas concéntricas, donde cada capa depende
únicamente de la inmediatamente interna.

✨ Ventajas de la Arquitectura Onion

📂 Separación de responsabilidades: Cada capa tiene una función única, mejorando la organización del código.
🔄 Adaptabilidad: Permite modificar componentes de infraestructura sin afectar la lógica de negocio.
✅ Testabilidad: Facilita pruebas unitarias e integradas sin depender de servicios externos.
2. 📊 Diagrama de la Arquitectura Onion

En el diagrama se observa cómo las capas externas interactúan unidireccionalmente con las internas. Esta estructura mantiene el núcleo protegido de

🏗️ Descripción de Cada Capa

dependencias externas.

3.
🧩 Capa de Dominio (Domain Layer)
La Capa de Dominio es el núcleo de la aplicación y contiene las entidades, objetos de valor y reglas de negocio. Esta capa es completamente
independiente y no tiene dependencias hacia otras capas o frameworks externos.

🔄 Capa de Aplicación (Application Layer)

La Capa de Aplicación coordina los casos de uso y servicios. Se encarga de gestionar el flujo de negocio, utilizando las entidades y objetos de valor
de la capa de dominio.

🌐
🌐 Capa de Infraestructura (Infrastructure Layer)
La Capa de Infraestructura implementa las dependencias externas de la aplicación, como la persistencia de datos y la interacción con APIs

🔀 Flujo de Trabajo y Comunicación Entre Capas y Módulo Commons

externas. Esta capa depende de las interfaces definidas en la Capa de Dominio.

4.

La comunicación sigue estas reglas:

1. Capa de Interfaces invoca los servicios de la Capa de Aplicación.

2. Capa de Aplicación gestiona la lógica de negocio, trabajando con las entidades de la Capa de Dominio.
3. Capa de Infraestructura accede únicamente a través de las interfaces definidas en el Dominio.

💡 Nota: El módulo commons proporciona funcionalidades base, como se observa en el diagrama. Este módulo hereda e implementa funciones clave

🎯 Principios de Diseño Aplicados

para los otros componentes.

5.
🔧 Inversión de Dependencias: La Infraestructura implementa interfaces del Dominio, garantizando que las dependencias externas no afecten el
núcleo de la aplicación.

📏 Separación de Responsabilidades: Cada capa tiene una función clara, promoviendo modularidad y claridad en el código.
🧪 Testabilidad: La arquitectura permite pruebas unitarias en el núcleo sin depender de servicios externos, gracias al uso de interfaces para
📘 Conclusión y Buenas Prácticas
manejar dependencias.

6.
La Arquitectura Onion garantiza que el núcleo de la aplicación permanezca independiente de frameworks y herramientas externas, facilitando la
escalabilidad y el mantenimiento a largo plazo.

✅ Buenas Prácticas:
Aplicar los principios SOLID.
Respetar la separación estricta entre capas.
Asegurar que las dependencias siempre apunten hacia el núcleo.

¡Sigue estas recomendaciones para un proyecto robusto y mantenible! 🚀

User Stories
Last edited by Edwin Arias 4 weeks ago

US1.1 - Solicitud de Tarjeta de Crédito

Como usuario del sistema quiero solicitar una tarjeta de crédito para poder realizar compras y acceder a servicios financieros

Criterios de Aceptación:

El sistema debe permitir ingresar la siguiente información del solicitante:

Nombre completo
Correo electrónico
Dirección
Ingresos mensuales
El sistema debe validar que los campos obligatorios estén completados.
El sistema debe permitir adjuntar archivos personales del solicitante:
El sistema debe generar una solicitud única y proporcionar al solicitante un mensaje de confirmación de la recepción de la solicitud.
El sistema debe enviar una notificación al solicitante confirmando que su solicitud ha sido recibida correctamente.

Dependencias:

Se debe tener una base de datos:

Sub Tareas:

Crear un formulario para ingresar los datos del solicitante.

Implementar validaciones de campos obligatorios y correctitud de la información.
Diseñar e implementar la lógica de negocio para almacenar la solicitud en la base de datos.

Mockup

US1.2 - Seguimiento de Solicitud de Tarjeta

Como usuario del sistema quiero poder hacer el seguimiento del estado de mi solicitud para saber si ha sido aprobada.

Criterios de Aceptación:

El sistema debe mostrar una pantalla de "en revisión" mientras se revisa la solicitud enviada preciamente
El sistema debe enviar una notificación de aceptación o rechazo de la solicitud por correo.
El sistema debe notificar al solicitante por correo electrónico cuando su solicitud haya sido aprobada o rechazada.
En caso de aprobación, el correo debe contener detalles sobre los siguientes pasos, incluyendo la activación y envío de la tarjeta.
En caso de rechazo, el correo debe detallar los motivos del rechazo y, si es posible, ofrecer recomendaciones para futuras solicitudes.

Dependencias:
 Se debe tener la US1.1 realizada y funcional.

Sub Tareas:

Implementar la lógica para mostrar la pantalla de "en revisión".

Implementar la funcionalidad para enviar notificaciones por correo electrónico.
Crear plantillas de correo separadas para notificaciones de aprobación y rechazo.

Mockups*

US1.3 -Adjuntar Archivos en la Solicitud de Tarjeta de Crédito

Como cliente, quiero poder adjuntar archivos durante el proceso de solicitud de una tarjeta de crédito, para proporcionar documentos adicionales que
respalden mi solicitud.

Criterios de Aceptación:

El formulario de solicitud debe permitir la carga de archivos (PDF, imágenes).

El cliente debe poder adjuntar múltiples archivos en una misma solicitud.
Debe haber validación de los tipos de archivos permitidos y un tamaño máximo para cada archivo.
El sistema debe confirmar que los archivos se han subido correctamente.

Dependencias:

Debe haberse realizado por completo la US1.1.

Subtareas:

Implementar el campo de carga de archivos en el formulario de solicitud de tarjeta de crédito.

Permitir la selección y carga de múltiples archivos en la misma solicitud.
Validar los tipos de archivos permitidos (PDF, JPG, PNG) y mostrar mensajes de error para tipos no permitidos.
Implementar validación del tamaño máximo de archivos (5 MB) y mostrar un mensaje de error si se excede.
Implementar la lógica en el backend para procesar y almacenar los archivos subidos.
Mostrar una confirmación en el frontend cuando los archivos se carguen correctamente.
Asociar los archivos subidos con la solicitud correspondiente en la base de datos.

Mockup
US1.4 - Creación de Base de Datos para la Gestión de Solicitudes y
Transacciones de Tarjetas de Crédito
Como desarrollador, quiero crear una base de datos para gestionar las solicitudes de tarjetas de crédito y registrar las transacciones de los usuarios,
para almacenar la información de manera estructurada y segura.

Criterios de aceptación:

La base de datos debe tener una tabla para almacenar la información de los solicitantes (nombre, correo, teléfono, dirección, ingresos mensuales).
La base de datos debe incluir una tabla para las solicitudes, que registre el estado (pendiente, aprobada, rechazada) y los archivos adjuntos.
Debe haber una tabla para almacenar las transacciones realizadas con las tarjetas de crédito.
Las transacciones deben incluir detalles como la fecha, monto, descripción de la transacción y el ID de la tarjeta.
Debe haber relaciones adecuadas entre las tablas de usuarios, solicitudes y transacciones.
El sistema debe permitir la consulta y modificación de los registros por parte de administradores y usuarios autenticados.

Subtareas:

Diseñar el esquema de la base de datos, incluyendo las tablas necesarias para almacenar la información de los solicitantes, las solicitudes y las
transacciones.
Crear una tabla para almacenar los datos del solicitante: nombre completo, correo electrónico, teléfono de contacto, dirección, ingresos mensuales.
Crear una tabla para gestionar las solicitudes de tarjeta de crédito: estado de la solicitud, fecha de creación, archivos adjuntos.
Crear una tabla de transacciones que registre la fecha, monto, descripción de la transacción y el ID de la tarjeta de crédito.
Establecer relaciones entre las tablas de usuarios, solicitudes y transacciones de tarjetas de crédito.
Implementar la lógica para insertar, actualizar y eliminar registros en la base de datos.

Diseño de la base de datos

US1.5 - Asignación de Tarjeta de credito a cada usuario
Como administrador del sistema, quiero asignar una tarjeta de crédito a cada usuario aprobado, para que puedan comenzar a usarla.

Criterios de Aceptación:

El sistema debe permitir asignar una tarjeta de crédito a un usuario previamente aprobado.
El sistema debe almacenar los datos de la tarjeta (número, límite de crédito, fecha de expiración).
Se debe enviar una notificación al usuario con la información de la tarjeta asignada.

Dependencias:

Base de datos para almacenar los datos de tarjetas y usuarios.

US1.4 funcional.
US1.1 funcional.
US1.2 funcional.

Sub Tareas:

Implementar la lógica para generar una tarjeta y asignarla al usuario.

Almacenar los datos de la tarjeta en la base de datos.
Enviar notificaciones al usuario sobre la asignación exitosa.

US2.1 - Visualización de historial de transacciones de tarjeta de crédito:

Como cliente bancario,quiero visualizar todas las transacciones realizadas con la tarjeta de crédito, para poder gestionar de mejor manera el gasto.

Criterios de Aceptación:

El cliente puede visualizar una lista de todas las transacciones de su tarjeta de crédito en la pantalla.
Las transacciones están ordenadas de la más reciente a la más antigua por defecto.
La lista de transacciones se actualiza automáticamente con nuevas transacciones.
Dependencia:

Tener usuario registrado como también tarjeta de crédito

Sub Tareas:

Implementar una interfaz grafica para visualizar las transacciones

Implementar las cards en donde se mostrara la información de las transacciones.
Desarrollar la logica la cual nos permitira actualizar automaticamente la lista de transacciones
Configurar y optimizar la conexión a la base de datos para poder optener todas las trasnsacciones de la tarjeta de credito del usuario.

Mackup

US2.2 - Filtrado de historial entre rangos de fecha

Como cliente bancario, quiero poder filtrar el historial de transacciones por un rango de fechas específico, para revisar mis gastos en un período
determinado.

Criterios de Aceptación:

El cliente puede seleccionar un rango de fechas utilizando un selector de fechas.

Al aplicar el filtro, solo se muestran las transacciones que caen dentro del rango de fechas seleccionado.

El usuario puede restablecer el filtro para volver a ver todas las transacciones.

Si no existen transacciones en el rango de fechas especificado, se muestra un mensaje informativo indicando que no hay resultados.

Dependencia:

US2.1 - Visualización de historial de transacciones de tarjeta de crédito

Sub Tareas:

Implementar en la interfaz un selector de fechas en donde seleccionaremos la fecha a filtrar.

Implementar un botón para restablecer el historial de transacciones.
Implementar la funcionalidad que permite filtrar las transacciones segun el rango de fechas seleccionado.
Desarrollar la logica que muestre el mensaje informativo en la interfaz cuando no exista transacciones en el rango de fechas seleccionado.

Mackup
US2.3 - Visualización del límite de la tarjeta de crédito:
Como cliente bancario, quiero ver el límite total de mi tarjeta de crédito, para planificar mis compras.

Criterios de Aceptación:

El cliente puede ver el límite total de su tarjeta de crédito en una sección de la pantalla, de manera grafica.

El límite se muestra de manera destacada y junto al saldo actual de crédito y el crédito disponible.

El límite total es preciso y se actualiza si hay cambios en el límite de crédito del usuario.

Dependencia:

Tener usuario registrado como también tarjeta de crédito

Sub Tareas:

Crear el diseño de la sección en la pantalla donde se mostrará el límite total de la tarjeta de crédito.
Desarrollar la funcionalidad que permite, que el limite total, el saldo actual de credio y el credito disponible se actualice automaticamente cuando
haya modifiacciones.
Optimizar el porceso de consultas y visualización de datos para minimizar la carga de la base de datos y mejorar l avelocidad de respuesta de la
interfaz.
Crear mensajes de error y notificaciones que se muestren si hay algun problema la momento de obtener los datos del límite de crédito, saldo actual,
o crédito disponible.

Mackup

US2.4 - Visualización del saldo actual y crédito disponible de la tarjeta:

Como cliente bancario, quiero ver mi saldo actual de crédito y el crédito disponible, para poder gestionar mis compras de manera más efectiva.

Criterios de Aceptación:

El usuario puede ver el saldo actual y el crédito disponible en una sección de la pantalla.

El crédito disponible se calcula en base al límite total menos el saldo actual.

El saldo actual y el crédito disponible se actualizan en tiempo real con las transacciones.

Dependencia:

Tener usuario registrado como también tarjeta de crédito.

 US2.3 correctamente implementada.

Sub tareas:

Crear una representacion grafica (como una barra o gráfico circular) para mostrar el saldo actual y el crédito disponible de la tarjeta.
Desarrollar la logica para calcular el crédito disponible en tiempo real.
Configurar una conexión para el saldo actual y el crédito disponible se actualicen en tiempo real a medida que se procesen nuevas transacciones.

Mackup

US2.5 - Creación del reporte mensual

Como cliente bancario, quiero recibir un reporte mensual de mis transacciones de tarjeta de crédito, incluyendo información detallada de mis gastos,
para poder revisar y analizar mis movimientos financieros.

Criterios de Aceptación:

El reporte incluye el monto total de las transacciones, el balance inicial y final, y un desglose detallado de cada transacción (fecha, descripción,
monto).

El reporte cubre todas las transacciones del mes y está disponible el primer día del mes siguiente.

El usuario recibe un reporte mensual en formato PDF o a través de un enlace de descarga en la aplicación.

Dependencia:

US2.1 - Visualización de historial de transacciones de tarjeta de crédito

US2.6 - Funciona correctamente.

Sub Tareas

Implementar la lógica para generar reportes mensuales con el monto total de transacciones, balance inicial y final, y un desglose detallado de cada
transacción.
Crear la funcionalidad para generar el reporte en formato PDF.
Asegurar que el acceso a los reportes esté protegido mediante autenticación segura.

Mackup
US2.6 Envio de reporte al correo electronico del usuario
Como cliente bancario, quiero recibir un reporte de mi tarjeta cuando esté disponible, para poder visualizar de manera clara mi historial de
transacciones, así como el saldo actual, el monto límite y el crédito disponible de mi tarjeta.

Criterios de Aceptación

Cuando el reporte este listo este se enviara de manera automatica al correo del usuario.
El reporte debe incluir el historial de transacciones, el saldo actual, el monto límite de la tarjeta y el crédito disponible.
El reporte debe reflejar las transacciones y datos más recientes de la tarjeta hasta el momento de su generación.

Sub Tareas

Crear la funcionalidad para enviar notificaciones (correo electronico) cuando el reporte de la tarjeta este disponible

Mackup

US3.1 - Requisitos de Seguridad en Activación/Desactivación

Como cliente bancario quiero que mi tarjeta de crédito solo pueda ser activada o desactivada tras un proceso de verificación para asegurarme de que
solo yo pueda cambiar el estado de mi tarjeta.

Criterios de Aceptación:

El sistema debe requerir autenticación del cliente antes de permitir cambios en el estado de la tarjeta.
 El sistema debe bloquear intentos de activación o desactivación si la autenticación falla más de 3 veces.

El cliente debe ser notificado si se bloquea la opción de cambiar el estado de la tarjeta debido a intentos fallidos de autenticación.

Dependencias

US3.2 Funciona correctamente.

US3.3 Funciona correctamente.

Sub Tasks

Crear un formulario de inicio de sesión que permita al cliente ingresar sus credenciales antes de realizar cambios en el estado de la tarjeta.

Si el cliente falla más de 3 veces, bloquear la opción de activar o desactivar la tarjeta durante un período de 30 minutos

Enviar una notificacion al correo, debe tener el motivo del bloqueo.

Mockup:

US3.2 - Desactivar Tarjeta de Crédito

Como cliente bancario con una tarjeta de crédito activa, quiero poder desactivar temporalmente mi tarjeta de crédito,para prevenir transacciones no
autorizadas cuando no esté en uso.

Criterios de Aceptación:

El sistema debe permitir al cliente desactivar su tarjeta desde la plataforma de manera sencilla

Al desactivar la tarjeta, el sistema debe mostrar un mensaje de confirmación al cliente.

El sistema debe impedir cualquier transacción con la tarjeta mientras esté desactivada.

El cliente debe poder ver el estado actual de su tarjeta (activa o desactivada).

El sistema debe registrar el cambio en el estado de la tarjeta, incluyendo la fecha y hora en que fue desactivada.

Dependencias

US3.2- Activar Tarjeta de Crédito

Sub Tasks

Crear un botón o enlace visible en la plataforma para desactivar la tarjeta de crédito.

Integrar con la base de datos para actualizar el estado de la tarjeta (de "activa" a "desactivada").

Al finalizar la desactivación, mostrar un mensaje de confirmación al cliente que indique que la tarjeta ha sido desactivada exitosamente y darle la
opcion de evita el comprobante al email.

Agregar una sección donde el cliente pueda ver claramente si su tarjeta está activa o desactivada.

Mockup
US3.3 - Activar Tarjeta de Crédito
Como cliente con una tarjeta de crédito desactivada, quiero poder reactivar mi tarjeta de crédito para volver a utilizarla para transacciones cuando lo
necesite.

Criterios de Aceptación:

El sistema debe permitir al cliente activar su tarjeta desactivada desde la plataforma.

Al activar la tarjeta, el sistema debe mostrar un mensaje de confirmación al cliente.

El sistema debe permitir transacciones con la tarjeta una vez que esté activada.

El cliente debe poder ver el estado actualizado de su tarjeta (activa o desactivada).

El sistema debe registrar el cambio en el estado de la tarjeta, incluyendo la fecha y hora en que fue activada.

Dependencias:

US3.2 Desactivar Tarjeta de Crédito

Sub Tasks

Crear un botón o enlace visible en la plataforma para desactivar la tarjeta de crédito.

Integrar con la base de datos para actualizar el estado de la tarjeta (de "activa" a "desactivada").

Al finalizar la activacion, mostrar un mensaje de confirmación al cliente que indique que la tarjeta ha sido activada exitosamente y darle la opcion de
evita el comprobante al email.

Agregar una sección donde el cliente pueda ver claramente si su tarjeta está activa o desactivada.

Mockup:

US3.4 - Mantener integro el historial de transacciones de la Tarjeta.

Como cliente bancario, quiero ver un historial de las transacciones de mi tarjeta de crédito para mantener siempre un control de tarjeta.

Criterios de Aceptación:

El sistema debe permitir al cliente acceder a un historial de las transacciones aun cuando la tarjeta esté desactivada.
 El historial debe incluir detalles relevantes para el historial de transacciones, deudas pendientes y fechas de creación y cierre, asegurando la
integridad y precisión de la información asociada.

El cliente debe poder ver al menos los últimos 10 cambios en el estado de su tarjeta.

Dependencias:

US3.2 Desactivar Tarjeta de Crédito

Sub Tasks

Crear una sección donde el cliente pueda acceder al historial de transacciones de su tarjeta de crédito.

Incluir información relevante en el historial, como:

Monto de la transacción.
Fecha y hora de la transacción.
Estado actual de la deuda (pagada o pendiente)

Implementar una funcionalidad que permita al cliente visualizar los últimos 10 cambios en el estado de su tarjeta (activación, desactivación, etc.).

Mockup:

US3.5 - Notificaciones de Cambios en el Estado de la Tarjeta

Como cliente bancario, quiero recibir una notificación cuando mi tarjeta de crédito sea activada o desactivada para estar informado de cualquier cambio
en el uso de mi tarjeta y evitar transacciones no autorizadas.

Criterios de Aceptación:

El sistema debe enviar una notificación cuando la tarjeta de crédito sea activada o desactivada.

La notificación debe incluir detalles como la fecha, hora, y acción realizada (activación o desactivación).

Dependencias

US3.2 Activar el envio de notificacion

US3.3 Activar el envio de notificacion

Sub Tasks

Establecer los formatos y plantillas para las notificaciones, debe incluir minimo la fecha, hora y la acción realizada (activación o desactivación).

Desarrollar la funcionalidad en el backend que envíe notificaciones cuando se active o desactive una tarjeta de crédito

Considerar permitir al cliente configurar sus preferencias de notificación (Email o Whatsapp)

US4.1 - Procesar Pago Manual de Tarjeta de Crédito

Como cliente con tarjeta de crédito, quiero realizar pagos manuales de mi saldo pendiente para tener control sobre mis pagos y decidir si abonar el
monto mínimo, total o un valor personalizado.

Criterios de Aceptación:

El cliente puede elegir entre diferentes opciones de pago: mínimo, total o personalizado.

El sistema verificará la cuenta bancaria del cliente antes de procesar el pago, asegurando que esté activa y tenga fondos.

Se enviará una notificación al cliente para confirmar el éxito o el fallo del pago.

Los detalles del pago manual quedarán registrados en el historial de transacciones de la tarjeta.
Dependencias:

US4.5: Verificación de fondos antes de procesar pagos manuales.

US4.3: Notificaciones de éxito o fallo del pago.

US4.4: Registro del pago en el historial de transacciones.

Modulo Cuenta

Modulo Transacción

Mockup

Subtareas:

Implementar interfaz para la selección del tipo de pago.

Enviar notificación del estado del pago.

Registrar el pago manual en el historial.

US4.2 - Configurar Pagos Recurrentes Automáticos

Como cliente, quiero establecer pagos automáticos para mi deuda de tarjeta de crédito, de modo que los pagos se realicen a tiempo y así evitar olvidos.

Criterios de Aceptación:

El cliente podrá definir la frecuencia del pago automático y si desea pagar el mínimo, el total o un monto personalizado.

El sistema validará la cuenta bancaria antes de programar el pago recurrente.

El cliente recibirá recordatorios antes de que se realice un cargo automático.

El cliente podrá pausar o cancelar los pagos recurrentes en cualquier momento.

Dependencias:

US4.5: Verificación de fondos antes de programar el pago automático.

US4.3: Notificaciones de cargos automáticos programados y procesados.

US4.4: Registro de cargos automáticos en el historial de pagos.

Modulo Cuenta

Modulo Transacción

Mockup
Subtareas:

Crear interfaz para configurar la frecuencia de pagos automáticos.

Añadir funcionalidad para pausar o cancelar los pagos.

Enviar recordatorios y notificaciones de éxito o fallo.

Registrar los pagos automáticos en el historial de transacciones.

US4.3 - Notificaciones de Pagos

Como cliente, quiero recibir notificaciones sobre mis pagos, para estar al tanto de si fueron procesados correctamente o si hubo algún problema.

Criterios de Aceptación:

El cliente recibirá notificaciones cuando se procese un pago manual o automático (pop up).

Las notificaciones indicarán si el pago fue exitoso o fallido, y mostrarán detalles como monto y fecha.

Se enviarán recordatorios antes de los cargos automáticos.

Dependencias:

US4.1: pagos manuales.

US4.2: pagos automáticos.

US4.5: Notificación si el pago falla por fondos insuficientes.

Modulo Cuenta

Modulo Transacción

Mockup
Subtareas:

Implementar sistema de notificaciones para pagos.

Diseñar mensajes personalizados para éxito, fallo o recordatorios.

Integrar las notificaciones con el historial de transacciones.

US4.4 - Consultar Historial de Pagos y Cargos Recurrentes

Como cliente, quiero revisar el historial de todos mis pagos y cargos recurrentes, para llevar un registro detallado de las transacciones realizadas con mi
tarjeta de crédito.

Criterios de Aceptación:

El cliente podrá ver una lista completa de los pagos y cargos realizados.

El historial mostrará detalles como fecha, monto y estado (exitoso o fallido).

El cliente podrá filtrar el historial por rango de fechas.

Dependencias:

US4.1: Los pagos manuales deben aparecer en el historial.

US4.2: Los cargos automáticos deben estar registrados en el historial.

US4.3: Las notificaciones de éxito o fallo deben estar reflejadas en el historial.

US2.2: Se usaria el codigo de filtrado.

 Modulo Cuenta

Mockups

Subtareas:

Crear interfaz para visualizar el historial de pagos y cargos.

Registrar correctamente los pagos manuales y automáticos.

Implementar filtros de búsqueda por fechas.

US4.5 - Verificación de Fondos Antes de Procesar Pagos

Como sistema bancario, quiero validar que la cuenta tenga fondos suficientes antes de procesar un pago, para asegurar que los pagos manuales y
automáticos se realicen sin problemas.

Criterios de Aceptación:

El sistema verificará los fondos de la cuenta antes de procesar cualquier pago.

Si no hay suficientes fondos, el sistema cancelará el pago y notificará al cliente.

Esta validación será aplicada tanto para pagos automáticos como manuales.

Dependencias:

US4.1: Verificación de fondos antes de procesar un pago manual.

US4.2: Validación de fondos antes de ejecutar un pago automático.

US4.3: Notificación en caso de fallo por falta de fondos.

Subtareas:

Implementar lógica de validación de fondos.

Integrar la validación con el procesamiento de pagos manuales y automáticos.

Notificar al cliente si el pago no puede ser procesado(POP UP)

4P's
Last edited by Edwin Arias 1 month ago
Casos de uso
Last edited by Edwin Arias 1 month ago

REQ-1

REQ-2

REQ-3

REQ-4
REQ-5
Design Patterns
🧠 Introducción a los Patrones de Diseño
Last edited by Edwin Arias 3 days ago

Los patrones de diseño son soluciones reutilizables a problemas comunes en el desarrollo de software. Ayudan a:

📚 Estandarizar la arquitectura.
⚡ Mejorar la flexibilidad y escalabilidad del sistema.
🛠️ Simplificar el mantenimiento y la comprensión del código.
🗂️ Lista de Patrones de Diseño
En este proyecto, hemos implementado varios patrones de diseño clave para garantizar que nuestro sistema sea eficiente, modular y fácil de extender.

A continuación, se presentan los patrones utilizados, con enlaces directos a su explicación:

🧩: Un patrón que asegura que una clase tenga solo una instancia y proporcione un punto global de acceso a ella.
[Link]

[Link]🎭: Proporciona una interfaz simplificada para un conjunto de interfaces en un subsistema, haciendo que el sistema sea más fácil de usar.

[Link]🏭: Un patrón para crear objetos sin especificar la clase exacta de objeto que se creará, promoviendo el principio de inversión de
dependencias.

[Link]🖌️: Permite la creación de objetos basados en un prototipo existente, clonándolo en lugar de crear nuevas instancias desde cero.
Singleton Pattern

🧩 Singleton Pattern
Last edited by Edwin Arias 3 days ago

El patrón de diseño Singleton se utiliza para gestionar el inicio de sesión y garantizar que solo haya una instancia activa durante la sesión. Esto permite

🌟 Beneficios del Singleton

identificar al usuario actual de manera eficiente y personalizar los datos según sea necesario.

Instancia Única: Garantiza que solo exista un objeto que represente al usuario autenticado.
Acceso Global: Facilita el acceso al usuario actual desde cualquier parte de la aplicación.

🏗️ Estructura del Singleton

Eficiencia: Evita la duplicación de instancias, mejorando el rendimiento.

Se define la clase CurrentUserSingleton , que asegura que solo exista una instancia activa del usuario. Esta clase incluye:

currentUser: Representa al usuario autenticado.

userMapper: Realiza la conversión entre el objeto de transferencia de datos (UserDTO) y la entidad (User).
@Getter : Proporciona acceso global al usuario actual.

🛠️ Creación y Acceso a la Instancia

Funcionalidad:
1. Creación de la instancia:
Si no existe una instancia, se crea con los datos del usuario autenticado.
2. Actualización del usuario:
Si ya existe una instancia, compara el usuario proporcionado con el actual. Si son diferentes, actualiza la información.
3. Acceso a la instancia:
Permite obtener la instancia actual, siempre que haya sido inicializada.
🔄 Modificación y Limpieza del Usuario
Métodos:
1. Actualizar usuario:
El método setCurrentUser(UserDTO currentUser) actualiza el usuario con uno nuevo.
2. Limpiar usuario:
El método setCurrentUser() elimina los datos del usuario actual, estableciendo currentUser en null , indicando que no hay un usuario
activo.
Facade
Last edited by Cristian Galeano 3 weeks ago

Utilizamos el patrón de diseño Facade para simplificar la interacción entre el controlador y las diversas clases de servicio y mapeo relacionadas con la
solicitud y seguimiento de tarjetas de crédito. Este patrón surgió de la necesidad de centralizar la lógica, permitiendo que los controladores se enfoquen
solo en la lógica de la interfaz de usuario (UI). Con Facade, reducimos la complejidad en los controladores, haciendo que el código sea más limpio y fácil
de mantener.

Estructura básica del Facade

En esta primera sección, definimos la clase CreditCardFacade, que actúa como una fachada. Esta clase contiene referencias a las dependencias
principales (UserService y UserMapper), necesarias para realizar operaciones relacionadas con los usuarios. En lugar de que los controladores
gestionen directamente estos servicios y mapeadores, delegamos la responsabilidad al Facade. Esto asegura que cualquier operación relacionada con la
solicitud o seguimiento de una tarjeta de crédito esté centralizada aquí.

Creación e Interacción con el Facade

En esta parte, definimos los métodos handleRequestCreditCardView() y showTrackRequestView() en la fachada. Estos métodos simplifican el flujo de
interacción para el controlador:

handleRequestCreditCardView() cambia la vista a la de solicitud de tarjeta de crédito.

showTrackRequestView() verifica si el usuario actual es un administrador y, en función de ello, selecciona la vista adecuada de seguimiento de
solicitud de tarjeta de crédito.

Gracias a esta estructura, el controlador solo necesita llamar a estos métodos sin preocuparse por la lógica o detalles de implementación. Esto permite
una interacción limpia y sencilla desde el controlador, sin necesidad de manejar servicios y validaciones complejas.

Uso del Facade en el Controlador

Finalmente, en el HomeViewController, instanciamos CreditCardFacade y utilizamos sus métodos para manejar la solicitud y el seguimiento de las
tarjetas de crédito. Los métodos handleRequestCreditCard(ActionEvent event) y showTrackRequestView(ActionEvent event) en el controlador ahora se
limitan a invocar los métodos de CreditCardFacade. Esto permite que el controlador esté enfocado en la UI y delegue toda la lógica de negocio al
Facade, mejorando así la separación de responsabilidades.
Factory
Last edited by Said Acosta 3 weeks ago

Patron Metodo Factory

Utilizamos el patrón Factory en las clases CreditCardFactory , PaymentFactory , RequestFactory , TransactionFactory , UserFactory . Para este
ejemplo, utilizaremos la clase RequestFactory .

La clase RequestFactory es la responsable de crear y gestionar una instancia de RequestService . La intención de la clase Factory es que otras partes
del código puedan obtener una instancia de la clase RequestService sin que las clases tengan detalles de su creación o configuración. Este es un
patrón de Factory Method, ya que encapsula la lógica de creación dentro de un método estático.

package [Link];

import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];

public class RequestFactory {

private static RequestService requestService;

private RequestFactory() {

public static RequestService requestService() {

if (requestService == null) {
EntityManagerFactory entityManagerFactory = [Link]("default");
EntityManager entityManager = [Link]();
RequestRepository requestRepository = new RequestRepositoryImpl(entityManager);
RequestMapper requestMapper = new RequestMapper();
requestService = new RequestServiceImpl(requestRepository, requestMapper);
}
return requestService;
}
}

El método requestService es donde estamos implementando el patrón de diseño. La función verifica si la instancia de requestService es nula. En
caso de que lo sea, crea y configura todos los objetos necesarios para luego instanciar la clase RequestServiceImpl . Después de esto, devuelve la
instancia de RequestService , lo que permite al cliente o usuario obtener una instancia sin la necesidad de conocer los detalles de cómo se crea.

La clave del patrón se encuentra en el método requestService() , ya que este oculta el proceso de creación del objeto de la clase
RequestServiceImpl , agregando todas las dependencias como EntityManager y RequestRepository .

En el caso de las demás clases, es igual, ya que se implementa la misma lógica para todas. Lo único que cambia es que cada clase hace referencia a las
clases con las que trabaja. A continuación, se adjuntan las demás clases, en donde se evidencia que tienen la misma lógica; por lo tanto, estas clases
también implementan el patrón de diseño Factory.

CreditCardFactory

package [Link];

import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
 import [Link];

public class CreditCardFactory {

private static CreditCardService creditCardService;

private CreditCardFactory() {

public static CreditCardService creditCardService() {

if (creditCardService == null) {
EntityManagerFactory entityManagerFactory = [Link]("default");
EntityManager entityManager = [Link]();
CreditCardRepository creditCardRepository = new CreditCardRepositoryImpl(entityManager);
CreditCardMapper creditCardMapper = new CreditCardMapper();
creditCardService = new CreditCardServiceImpl(creditCardRepository, creditCardMapper);
}
return creditCardService;
}
}

TransactionFactory

package [Link];

import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];

public class TransactionFactory {

private static TransactionService transactionService;

private TransactionFactory() {
}

public static TransactionService transactionService() {

if (transactionService != null) {
return transactionService;
}

EntityManagerFactory entityManagerFactory = [Link]("default");

EntityManager entityManager = [Link]();

TransactionRepository transactionRepository = new TransactionRepositoryImpl(entityManager);CreditCardRep

TransactionMapper transactionMapper = new TransactionMapper();

transactionService = new TransactionServiceImpl(transactionRepository, transactionMapper);

return transactionService;
}
}
UserFactory

package [Link];

import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];

public class UserFactory {

private static UserService userService;

private UserFactory() {
}

public static UserService userService() {

if (userService != null) {
return userService;
}
EntityManagerFactory entityManagerFactory = [Link]("default");
EntityManager entityManager = [Link]();

UserRepository userRepository = new UserRepositoryImpl(entityManager);

UserMapper userMapper = new UserMapper();

userService = new UserServiceImpl(userRepository, userMapper);

return userService;
}
}

PaymentFactory

package [Link];

import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];

public class PaymentFactory {

private static PaymentService paymentService;

private PaymentFactory() {

public static PaymentService paymentService() {

if (paymentService != null) {
return paymentService;
}

EntityManagerFactory entityManagerFactory = [Link]("default");

EntityManager entityManager = [Link]();

PaymentRepository paymentRepository = new PaymentRepositoryImpl(entityManager);

PaymentMapper paymentMapper = new PaymentMapper();
 paymentService = new PaymentServiceImpl(paymentRepository, paymentMapper);

return paymentService;
}
}
Prototype
Last edited by Catriel21 3 weeks ago

Implementación del Patrón Prototype en CreditCardDTO

Introducción
El patrón Prototype es un patrón de diseño creacional que permite crear nuevos objetos clonando una instancia existente. En nuestra aplicación, hemos
implementado este patrón en la clase CreditCardDTO , que representa los datos de una tarjeta de crédito. Esto nos permite crear nuevas instancias de
CreditCardDTO sin la necesidad de inicializar todos los atributos cada vez, facilitando la creación de objetos similares.

Clase CreditCardDTO
La clase CreditCardDTO se define en el paquete [Link] y está estructurada de la siguiente manera:

package [Link];

import [Link];
import [Link];
import [Link];
import [Link];
import [Link];

@Data
@Builder
public class CreditCardDTO implements Cloneable {
private Long id;
private String cardNumber;
private LocalDateTime expirationDate;
private int cvc;
private BigDecimal creditLimit;
private BigDecimal currentBalance;
private LocalDateTime createdAt;
private StatusCreditCard status;
private Long userId;

@Override
public CreditCardDTO clone() {
try {
return (CreditCardDTO) [Link](); // Clonación superficial
} catch (CloneNotSupportedException e) {
throw new RuntimeException("Error al clonar CreditCardDTO", e);
}
}
}

Atributos
id : Identificador único de la tarjeta de crédito.
cardNumber : Número de la tarjeta de crédito.
expirationDate : Fecha de expiración de la tarjeta.
cvc : Código de verificación de la tarjeta.
creditLimit : Límite de crédito asignado a la tarjeta.
currentBalance : Saldo actual de la tarjeta.
createdAt : Fecha de creación de la tarjeta.
status : Estado actual de la tarjeta de crédito.
userId : Identificador del usuario asociado con la tarjeta.

Implementación del Método Clone

El método clone() permite realizar una clonación superficial de la instancia de CreditCardDTO . Si se desea realizar una clonación profunda (en caso
de que existan atributos mutables), se deberán implementar las copias de esos atributos manualmente.
Uso del Patrón Prototype
Servicio de Tarjeta de Crédito
En la clase de servicio CreditCardService , podemos utilizar el método de clonación para crear nuevas instancias de CreditCardDTO a partir de un
prototipo. A continuación se muestra un ejemplo de cómo se puede implementar:

public class CreditCardService {

private final CreditCardDTO creditCardPrototype;

public CreditCardService(CreditCardDTO creditCardPrototype) {

[Link] = creditCardPrototype;
}

public CreditCardDTO createNewCreditCard() {

CreditCardDTO newCreditCard = [Link]();
// Modificar el nuevo DTO si es necesario
[Link](null); // Por ejemplo, asignar un nuevo ID o dejarlo como null
return newCreditCard;
}
}

Consideraciones al Clonar
Clonación Superficial: La clonación se realiza de manera superficial. Si se tiene atributos mutables, se debe considerar la implementación de una
clonación profunda para evitar efectos indeseados.
Gestión de IDs: Es recomendable establecer el id en null al crear un nuevo DTO que se persistirá en la base de datos.

Conclusión
La implementación del patrón Prototype en CreditCardDTO simplifica la creación de nuevas instancias de este objeto, mejorando la eficiencia y la
claridad del código en la capa de aplicación. Este enfoque respeta la arquitectura Onion al mantener separadas las preocupaciones de creación y
transporte de datos.
Epics
Last edited by Cristian Galeano 1 month ago

Epic 1: Gestionar creación de Tarjetas de Crédito

Descripción: Desarrollar una funcionalidad que permita a los clientes acceder y gestionar todo el ciclo de vida de sus tarjetas de crédito. Esto incluirá la
solicitud de nuevas tarjetas, el seguimiento del proceso de aprobación de la tarjeta Los usuarios podrán solicitar una tarjeta de crédito a través del
sistema, gestionar sus preferencias de uso y monitorear su actividad financiera.

Criterios de Éxito:

Los clientes pueden solicitar una tarjeta de crédito a través de la plataforma digital.
El sistema notifica a los clientes si se aprobó o no su solicitud.
Toda la información de la tarjeta está actualizada y es accesible en cualquier momento.

Dependencias:

Integración con las cuentas de los usuarios

Base de datos para gestionar las solicitudes

Estimación

L (Large)

User Storys.

US1.1 - Solicitud de tarjeta.

US1.2 - Seguimiento de Solicitud de Tarjeta.
US1.3 - Adjuntar Archivos en la Solicitud Tarjeta de Credito.
US1.4 - Creacion de Base de datos para la Gestion de Solicitud y Transacciones de Tarjetas de Credito.
US1.5 - Asignacion de Tarjeta de credito a cada usuario.

Epic 2: Gestión integral de información de tarjetas de Credito.

Descripción: Desarrollar una funcionalidad que permita a los clientes acceder y gestionar el historial de transacciones de su tarjeta de crédito.

Criterios de Éxito:

Los usuarios pueden visualizar todas las transacciones realizadas con la tarjeta.
Los clientes pueden especificar un rango de fechas para filtrar las transacciones.
Los usuarios pueden ver su límite de crédito, saldo actual y su crédito disponible.

Dependencias:

Esta épica se basa en aquellos usuarios que cumplen la primera épica es decir que tienen una tarjeta de crédito.
Sistemas de autenticación de usuarios.
Base de datos de transacciones de tarjetas de crédito.

Estimación:

User Storys.

US2.1 - Visualizacion de historial de transacciones de tarjetas de credito.

US2.2 - Filtrado de historial entre rangos de fechas.
US2.3 - Visualizacion del limite de la tarjeta de credito.
US2.4 - Visualizacion del saldo actual y credito disponible de la tarjeta.
US2.5 - Creacion del reporte mensual.
US2.6 - Envio de reporte al correo electronico del usuario.

Epic 3: Gestión Activación y Desactivación de Tarjetas

Descripción: Esta épica permitirá a los clientes activar o desactivar temporalmente sus tarjetas de crédito a través de la plataforma bancaria. La
funcionalidad asegurará que los clientes tengan control sobre el uso de sus tarjetas en cualquier momento, previniendo transacciones no autorizadas y
brindando tranquilidad. Manteniendo el historial de las tarjetas aun si están desactivadas.

Criterios de Exito:

Los clientes pueden activar o desactivar la su tarjeta de credito de manera sencilla

La desactivación de la tarjeta debe impedir cualquier transacción futura
El sistema debe registrar y mantener el historial de cambios en el estado de la tarjeta, incluyendo fechas y detalles relevantes
Dependecias:

Esta épica se basa en aquellos usuarios que cumplen la primera épica es decir que tienen una tarjeta de crédito.

Estimacion:

User Storys.

US3.1 - Requisitos de Seguridad en Activacion/Desactivacion.

US3.2 - Desactivar Tarjeta de credito.
US3.3 - Activar de Tarjeta de credito.
US3.4 - Mantener integro el historial de transacciones de la Tarjeta.
US3.5 - Notificaciones de cambio en el estado de tarjeta.

Epic 4: Gestión de Pagos y Cargos Automáticos Descripción: Esta epic permitirá brindar a los clientes la capacidad de efectuar pagos de las deudas
acumuladas en su tarjeta de crédito, tanto de forma manual como automática. Este proceso se diseñará con transparencia y eficiencia, otorgando a los
usuarios un control total sobre sus pagos y facilitando la gestión de sus obligaciones financieras. Criterios de Éxito:

El sistema permite a los usuarios realizar pagos manuales de su deuda acumulada en la tarjeta de crédito, ofreciendo opciones como el pago
mínimo, el pago total o un monto específico ingresado por el usuario.
El sistema valida que la cuenta bancaria del usuario esté activa y tenga suficientes fondos antes de realizar un cargo automático o un pago manual.
Los usuarios reciben notificaciones sobre el estado de los pagos automáticos y manuales (éxito, fallo, fondos insuficientes).
Los registros de pagos y cargos automáticos están disponibles para que los usuarios los consulten en su historial de transacciones.

Estimación:

Users Storys.

US4.1 - Procesar pago manual de tarjeta de credito.

US4.2 - Configurar pagos recurrentes automaticos.
US4.3 - Notificacion de Pagos.
US4.4 - Consultar historial de pagos y cargos recurrentes.
US4.5 - Verificacion de fondos antes de procesar pagos.
Meeting Notes
Last edited by Cristian Galeano 4 weeks ago

Sprint 0

Planning Meeting: 03/10/2024

Meeting: 04/10/2024

Daily Meeting: 08/10/2024

Daily Meeting: 10/10/2024

Retrospective: 11/10/2024

Sprint 1

Daily Meeting: 17/10/2024

Daily Meeting: 18/10/2024

Daily Meeting: 21/10/2024

Daily Meeting: 24/10/2024

Sprint review: 24/10/2024

Pipeline
Last edited by Catriel21 1 week ago

Una pipeline (o "tubería") en el contexto del desarrollo de software es un conjunto de pasos automatizados que permiten la integración y entrega
continua (CI/CD) del código. Estas secuencias de pasos suelen incluir tareas como la compilación del código, la ejecución de pruebas, la revisión de
calidad del código, el despliegue en entornos de prueba y producción, entre otros.

El objetivo de una pipeline es garantizar que los cambios en el código se integren y se entreguen de manera eficiente y sin errores. Al automatizar estas
tareas, se mejora la productividad, se reduce el riesgo de errores manuales y se acelera el ciclo de desarrollo.

Pagina 1
Linter

Pagina 2
UnitTests

Pagina 3
Artefacts

Pagina 4
Coverage
Artefactos
Last edited by Cristian Galeano 1 week ago

Automatizar el proceso de compilación de la aplicación

Descripción del Pipeline
El bloque build está diseñado para compilar la aplicación y generar los artefactos resultantes en formato JAR utilizando Maven.

Cómo funciona este bloque:

Compilación y empaquetado:
Se ejecuta el comando mvn $MAVEN_CLI_OPTS clean package :
clean : Elimina cualquier archivo o carpeta generados previamente, asegurando una compilación limpia.
package : Compila el código fuente, ejecuta las pruebas y genera el artefacto final (normalmente un archivo JAR o WAR) en el directorio
target .

Publicación de artefactos:
El bloque artifacts guarda los artefactos generados en la carpeta target :
paths: target/*.jar : Especifica que solo se guarden los archivos JAR generados.
expire_in: 1 week : Define que los artefactos estarán disponibles por una semana en GitLab, tras lo cual serán eliminados automáticamente.

Ejemplo del Bloque en .[Link]

build:
stage: build
script:
- mvn $MAVEN_CLI_OPTS clean package
artifacts:
paths:
- target/*.jar
expire_in: 1 week
tags:
- gitlab-org
Coverage
Last edited by Cristian Galeano 1 week ago

El bloque coverage en el archivo de CI/CD está diseñado para automatizar la generación y publicación de informes de cobertura de código utilizando
JaCoCo, una herramienta de cobertura popular en proyectos basados en Java.

Cómo funciona este bloque:

1. Ejecución de pruebas con cobertura habilitada:

Se ejecuta el comando mvn $MAVEN_CLI_OPTS clean [Link]:jacoco-maven-plugin:prepare-agent test jacoco:report:

prepare-agent: Configura el agente de JaCoCo para rastrear la ejecución del código durante las pruebas.
test: Ejecuta todas las pruebas configuradas en el proyecto.
jacoco:report: Genera un reporte detallado de cobertura en formato HTML y XML en target/site/jacoco.

2. Análisis de cobertura en el pipeline:

El campo coverage: '/Total.*?([0-9]{1,3})%/' utiliza una expresión regular para buscar el porcentaje de cobertura total en los resultados de la
ejecución de pruebas.
Este valor puede ser usado por GitLab CI para monitorear y mostrar la cobertura directamente en la interfaz del pipeline.

3. Publicación de resultados:

Los reportes de cobertura se almacenan como artefactos en GitLab:

coverage_format: cobertura: Define el formato Cobertura, compatible con GitLab.
path: target/site/jacoco/[Link]: Especifica la ubicación del reporte XML.
Adicionalmente, se guardan todos los archivos generados en target/site/jacoco por una semana.
unit test
Last edited by Edwin Arias 2 weeks ago

Lineamientos de Pruebas Unitarias

1. Convenciones de Nombres
Formato de nombres:
Clases de Prueba: Las clases de prueba deben nombrarse siguiendo el formato [NombreClase]Test , como UsuarioServiceTest .
Métodos de Prueba: Los métodos deben seguir el formato accionEscenarioResultadoEsperado , por ejemplo,

guardarUsuario_shouldGuardarUsuarioExitosamente .

2. Organización de los Test

Estructura de Carpetas:
Crear una carpeta principal de pruebas que refleje la estructura de paquetes de producción, permitiendo la ubicación rápida de los archivos de
prueba.

Ejemplo:
Clases de Prueba:
Cada módulo (DTO, Entidad, Servicio) tendrá su propia clase de prueba que incluirá las pruebas específicas:
DTOs: Incluir entre 3-4 pruebas para validar conversiones y restricciones.
Entidades: Incluir al menos 7 pruebas para probar persistencia, integridad de datos y validaciones.
Servicios: Incluir al menos 6 pruebas que validen la lógica del servicio y los resultados de los métodos.

3. Manejo de Dependencias y Setup

Inyección de Dependencias:
Utilizamos un framework como JUnit y Mockito para gestionar dependencias y aislar las pruebas.
Setup:
Configurar un método @BeforeEach para inicializar las dependencias comunes antes de cada prueba, facilitando el mantenimiento y mejorando

la consistencia entre pruebas.

4. Manejo de Mockings
Mockito:
Utilizamos Mockito para simular dependencias externas o servicios que no se deseen llamar directamente en pruebas unitarias.
 Configuración de Mock:
Configurar los mocks en el método @BeforeEach , para que cada prueba comience con un estado limpio.
Usar métodos como when().thenReturn() para definir los comportamientos esperados de los mocks.

5. Cobertura de Código
Porcentaje Mínimo de Cobertura:
El porcentaje de cobertura es superior al 80%, con el fin de garantizar una prueba robusta del sistema.
Herramientas de Cobertura:
Con herramientas como JaCoCo podemos medir y analizar la cobertura de código.