-
Notifications
You must be signed in to change notification settings - Fork 0
Registros Hito 3
Este documento detalla la planificación, el diseño de la API REST, la estrategia de pruebas unitarias y los resultados del proceso de desarrollo e integración llevados a cabo para el Hito 3.
Para esta iteración, se priorizó el desarrollo de la siguiente historia de usuario basada en las estimaciones previas de Planning Poker:
- Historia de Usuario: HU010 - Seguimiento de Solicitud (Puntuación: 3 Story Points).
- Justificación: Permitir al usuario conocer en tiempo real el estado de su solicitud de crédito de consumo, asegurando transparencia en el proceso.
- Responsable de Desarrollo: Kran Olivares.
- Resultado: Implementada con éxito en el commit 0a8d172 (~4 horas de desarrollo).
Como parte de las tareas iniciales, se realizó una limpieza del repositorio y una adecuación del backend:
-
Limpieza: Se eliminó el archivo obsoleto
mock-api.js. -
Refactorización: Se actualizó
index.jspara estructurar y formatear los endpoints de manera clara siguiendo el estándar REST.
| Método | Endpoint | Historia de Usuario | Descripción / Comportamiento |
|---|---|---|---|
| POST |
/api/loans (con dryRun: true) |
HU001 (Simulación) | Permite calcular el valor de las cuotas sin persistir la información. |
| POST |
/api/loans (sin dryRun) |
HU005 (Creación) | Creación formal de una nueva solicitud de préstamo. |
| GET | /api/loans |
HU007 (Historial) | Obtiene la lista de préstamos del usuario autenticado de forma cronológica. |
| GET | /api/loans/:id |
HU007 (Detalle) | Visualización detallada de la información de una solicitud específica. |
Para asegurar la robustez de la API REST, se implementó una estrategia sistemática de pruebas bajo la siguiente metodología:
-
Nomenclatura de Ramas: Creación de ramas independientes con el formato
tests/<tema>-<nombre>. -
Casos de Prueba: Definición de clases de equivalencia y valores frontera, documentados en
README_tests.md. -
Implementación: Desarrollo de scripts de prueba en Python usando el framework
unittesty la libreríarequests.
A continuación, se detallan las pruebas desarrolladas, sus responsables, tiempos de implementación y capturas de éxito.
- Objetivo: Validar que el cálculo de la cuota mensual y el monto total de la simulación sea correcto y coherente.
- Responsable: Matías Romo.
- Esfuerzo: ~8 horas de desarrollo.
-
Resultado:
-
Objetivo: Validar la creación exitosa (código 201) con formato de ID
L-...y restringir el acceso sin token (código 401). - Responsable: Martina Madrid.
- Esfuerzo: ~5 horas de desarrollo.
-
Resultado:
- Objetivo: Validar que la lista obtenida contenga campos obligatorios (fecha, montos, estado) y respete el orden cronológico.
- Responsable: Alejandro Ortiz.
- Esfuerzo: ~7 horas de desarrollo.
-
Resultado:
- Objetivo: Validar la visualización completa de los campos del préstamo, así como el manejo de errores (404) para IDs inexistentes o de otros usuarios.
- Responsable: Vicente Jiménez.
- Esfuerzo: ~9 horas de desarrollo (repartidas en dos días).
-
Resultado:
Todas las pruebas unitarias y la HU010 fueron integradas de manera exitosa mediante Pull Requests a la rama main. Tras resolver un conflicto menor de dependencias en una de las ramas de prueba, el repositorio se encuentra estable y listo para la entrega.
- 🌐 Tablero de Trabajo: Tablero Digital DCC
- Estado de la Entrega: Todos los checks aprobados.