Pruebas realizadas - rBaku/Proyecto-LogisticaGlobal.com GitHub Wiki
La documentación de las pruebas realizadas hasta la entrega 1 se encuentran:
-
35 pruebas de Backend, realizando pruebas de integración, pruebas de peticiones HTTP de GET, POST, PUT y DELETE de las distintas APIs que se tiene en el sistema (robots, incidentes y técnicos). Cada prueba tiene una descripción de la petición HTTP realizada, los datos de entrada, el resultado esperado y el resultado obtenido. Se comprueba tanto la respuesta HTTP, como los cambios realizados en la base de datos PostgreSQL.
-
12 pruebas de Frontend, realizando pruebas unitarias manuales con los botones, formularios y registros que están disponibles en el sistema. La documentación de la pruebas detalla una descripción de la prueba realizada, los pasos realizados en la prueba, el resultado esperado y el resultado obtenido. Se revisa componente por componente (render, estado, eventos) directamente en el navegador.
Pruebas de Backend
- mocha
- chai (assertions)
- supertest (cliente HTTP)
- pgAdmin (base de Datos).
-
Módulos cubiertos: /api/robots, /api/incidentes, /api/tecnicos.
-
Cobertura: 26 casos ❯ 100 % de las rutas CRUD; incluye escenarios felices y errores por duplicados, claves foráneas y validaciones de dominio.
1- Suite de pruebas de robots
| Caso de prueba | Datos de entrada (método+ruta+body) | Resultado esperado | Resultado obtenido |
|---|---|---|---|
GET / debería devolver lista de robots |
GET /api/robots | 200 OK, array ⊇ RBT-TestGet1, RBT-TestGet2 | 200 OK, array contiene IDs sembrados |
GET /:id debería devolver un robot existente |
GET /api/robots/RBT-TestGet1 | 200 OK, objeto con id, name, is_operational | 200 OK, objeto correcto |
POST / debería crear un nuevo robot correctamente |
POST /api/robots { id:'RBT-TestCreate', name:'Robot Gamma', is_operational:true } | 201 Created + body ⊇ payload | 201 Created + body coincide |
POST / debería fallar si se intenta insertar un robot con un ID duplicado |
POST mismo id que ya existe | 4 xx (409/400) + error | 409 Conflicto + error |
POST / debería fallar si falta el campo id |
POST { name:'Faltante de ID', is_operational:true } | 400 Bad Request | 400 Bad Request |
POST / debería fallar si falta el campo name |
POST { id:'RBT-SinName', is_operational:true } | 400 Bad Request | 400 Bad Request |
PUT /:id debería actualizar un robot existente |
PUT /api/robots/RBT-TestGet1 { name:'Robot Beta', is_operational:false } | 200 OK + cambios reflejados | 200 OK + cambios aplicados |
PUT /:id debería devolver 404 si el robot no existe |
PUT /api/robots/NO-EXISTE … | 404 Página No encontrada | 404 Página No encontrada |
DELETE /:id debería eliminar un robot existente |
DELETE /api/robots/RBT-TestDelete | 204 No Content | 204 No Content + GET posterior no lo encuentra |
DELETE /:id debería devolver 404 si el robot no existe |
DELETE /api/robots/NO-EXISTE | 404 Página No encontrada | 404 Página No encontrada |
2- Suite de pruebas de los incidentes
| Caso de prueba | Datos de entrada (método+ruta+body) | Resultado esperado | Resultado obtenido |
|---|---|---|---|
GET / debería devolver una lista de incidentes |
GET /api/incidentes | 200 OK, array ⊇ INC-Test-001 | 200 OK, array incluye registro |
GET /:id debería devolver el incidente por UUID |
GET /api/incidentes/{uuid_existente} | 200 OK, objeto con campos clave | 200 OK |
GET /:id debería devolver 404 si no existe |
GET /api/incidentes/{uuid_fake} | 404 Página No encontrada | 404 Página No encontrada |
POST / debería crear un nuevo incidente correctamente |
POST /api/incidentes { robot_id:'RBT-X', assigned_technician_id:'TECH-X', gravity:5, … } | 201 Created, devuelve company_report_id | 201 Created + id devuelto |
POST / debería rechazar si faltan campos obligatorios |
POST (payload incompleto) | 400 Bad Request | 400 Bad Request |
POST / gravedad inválida < 1 |
gravity:-2 | 400 Bad Request | 400 Bad Request |
POST / gravedad inválida > 10 |
gravity:11 | 400 Bad Request | 400 Bad Request |
POST / gravedad inválida (no numérico) |
gravity:'alto' | 400 Bad Request | 400 Bad Request |
PUT /:id debería actualizar un incidente existente |
PUT /api/incidentes/{uuid} { status:'Resuelto', gravity:3 } | 200 OK + cambios | 200 OK |
PUT /:id debería devolver 404 si no existe |
PUT /api/incidentes/{uuid_fake} … | 404 Página No encontrada | 404 Página No encontrada |
DELETE /:id debería eliminar el incidente si existe |
DELETE /api/incidentes/{uuid} | 200/204, GET posterior → 404 | 204 Sin contenido + verificación ok |
DELETE /:id debería devolver 404 si no existe |
DELETE /api/incidentes/{uuid_fake} | 404 Página No encontrada | 404 Página No encontrada |
3- Suite de pruebas de los técnicos
| Caso de prueba | Datos de entrada (método+ruta+body) | Resultado esperado | Resultado obtenido |
|---|---|---|---|
GET / debería devolver lista de técnicos |
GET /api/tecnicos | 200 OK, array ⊇ TECH-TestGet1 | 200 OK |
GET /:id debería devolver el técnico solicitado |
GET /api/tecnicos/TECH-TestGet1 | 200 OK, objeto con id, full_name | 200 OK |
GET /:id debería devolver 404 si no existe |
GET /api/tecnicos/NO-EXISTE | 404 Página No encontrada | 404 Página No encontrada |
POST / debería crear un nuevo técnico |
POST { id:'TECH-Create', full_name:'Técnico Nuevo' } | 201 Created + body | 201 Created |
POST / debería retornar 400 si faltan campos |
POST { id:'TECH-Bad' } | 400 Bad Request | 400 Bad Request |
POST / debería retornar 409 si el id ya existe |
POST id duplicado (TECH-TestGet1) | 409 Conflicto + error | 409 Conflicto + error |
PUT /:id debería actualizar el nombre |
PUT /api/tecnicos/TECH-TestGet1 { full_name:'Técnico Beta' } | 200 OK + cambio | 200 OK |
PUT /:id debería devolver 400 si falta full_name |
PUT {} | 400 Bad Request | 400 Bad Request |
PUT /:id debería devolver 404 si no existe |
PUT /api/tecnicos/NO-EXISTE … | 404 Página No encontrada | 404 Página No encontrada |
PUT /:id debería devolver 409 si el nombre ya existe |
PUT → full_name:'Nombre Duplicado' existente | 409 Conflicto | 409 Conflicto |
DELETE /:id debería eliminar un técnico existente |
DELETE /api/tecnicos/TECH-TestDelete | 200 OK (o 204) | 200 OK, GET posterior → 404 |
DELETE /:id debería devolver 404 si no existe |
DELETE /api/tecnicos/NO-EXISTE | 404 Página No encontrada | 404 Página No encontrada |
DELETE /:id debería devolver 409 si tiene incidentes asociados |
DELETE /api/tecnicos/TECH-TestInUse (referenciado en Incidents) | 409 Conflicto | 409 Conflicto |
Pruebas de Frontend
- Herramientas de desarrollo del navegador.
- Checklist de casos de uso.
- Enfoque Pruebas: Enfoque inicial en formularios y tablas clave;
| Caso de prueba | Entrada / Acción (pasos) | Resultado esperado | Resultado obtenido |
|---|---|---|---|
Registro de Incidente – datos válidos |
1.Desde Landing pulsa “Registrar Incidente”. 2.Completa todos los campos del formulario: • Robot ID: RBT-UI-01 • Gravedad: 5 • Ubicación: “Bodega 2” … 3.Pulsa Guardar. | -Snackbar verde “Incidente creado con éxito”. -Redirección a “/incidentes”. -El nuevo incidente aparece en la tabla con mismo company_report_id. | OK |
Registro de Incidente – campo obligatorio vacío |
Repite Caso 1, pero deja location en blanco. | Se bloquea el envío. -Aparece helper-text en rojo “Ubicación requerida”. -Botón Guardar sigue deshabilitado. | OK |
Lista de Incidentes – filtrado por texto |
En “/incidentes” escribe RBT-UI-01 en el cuadro de búsqueda global. | La tabla muestra solo las filas cuyo robot_id contiene RBT-UI-01. | OK |
Edición de Incidente (Supervisor) |
1.En la fila del incidente creado abre menú … → Editar. 2.Cambia status a En progreso, gravity a 4. 3.Pulsa Guardar. | -Modal se cierra. -Snackbar verde “Actualizado”. -La fila refleja En progreso y gravedad 4. | OK |
Eliminación de Incidente |
En la misma fila menú … → Eliminar → confirmar. | -Snackbar Naranja “Incidente Eliminado”. -La fila desaparece de la tabla. | OK |
Registro de Robot – datos válidos |
1.Navega a “Estado de Robots”. 2.Pulsa Registrar robot. 3.Completa id: RBT-NEW, name: Robot Nuevo, ¿Esta operativo?: ✓. 4.Guardar. | -Snackbar “Robot creado”. -Tabla de robots incluye RBT-NEW con icono verde. | OK |
Registro de Robot – ID duplicado |
Repite Caso 6 con el mismo id: RBT-NEW. | -Snackbar/error rojo “ID duplicado (409)”. -El Dialog permanece abierto para corregir. | -Snackbar/error rojo “Conflict”. -El Dialog permanece abierto para corregir. |
Vista Técnico – sólo sus incidentes |
1.Simula login como Tecnico. 2.Abre “Mis Incidentes”. | Tabla muestra exclusivamente incidentes no resueltos | Tabla muestra todos los incidentes. |
Actualización por Técnico |
En “Ver incidentes”: 1.Selecciona un incidente → Actualizar. 2.Cambia status a En revisión y escribe comentario. 3.Guardar. | -Modal cierra. -Snackbar verde. -Fila refleja nuevo status; columna comentario actualizada. | OK |
Restricción de permisos |
Estando como Tecnico, intenta Eliminar un incidente desde menú …. | Opción “Eliminar” no está visible o devuelve Snackbar rojo “Acceso denegado”. | OK (Opcion no visible) |
UI / Responsive (tablet) |
Reduce viewport a 768 px, visita “/robots-estado”. | -Tabla pasa a scroll horizontal o columnas colapsan sin desbordes. -Botón FAB “Registrar robot” sigue visible. | OK |
Traza completa (flujo E2E manual) |
1.Supervisor crea incidente (Caso 1). 2.Supervisor asigna técnico TECH-alph(Editar). 3.TECH-alpha cambia status a Resuelto (Caso 9). 4.Supervisor filtra por Resuelto y cierra incidente (Editar → Cerrado). | -Cada transición muestra Snackbar éxito. -Historial/bitácora (si existe) registra los cambios de estado con timestamp y usuario. | OK |
Hay nuevas pruebas unitarias, las cuales son las siguientes:
Pruebas nuevas y Pruebas modificadas
Hay cambios en la suite, pero se eliminan los casos (POST) en que faltan name o ID y se compila en la prueba de que falte un campo obligatorio. Por otro lado, se separa el caso (PUT) en que se actualiza un robot existente a pruebas de actualizar name y estado; y un caso que falla si estado entregado no es valido
| Caso de prueba | Datos de entrada (método+ruta+body) | Resultado esperado | Resultado obtenido |
|---|---|---|---|
POST debería fallar si faltan campos obligatorios |
POST /api/robots | 400 Bad Request | 400 Bad Request |
PUT /:id debería actualizar un robot (name y state) |
PUT /api/incidentes/${incidenteId} | 200 nombre nuevo es Bot Actualizado y estado nuevo es Mantenimiento | 200 nombre="Bot actualizado" y estado=¨Mantenimiento¨ |
PUT /:id debería fallar si el estado no es string válido |
PUT /api/incidentes/${incidenteId} | 400 Bad Request | 400 Bad Request |
Nuevas pruebas relacionadas a incidentes
| Caso de prueba | Datos de entrada (método+ruta+body) | Resultado esperado | Resultado obtenido |
|---|---|---|---|
PUT /:id debería asignar updated_by y updated_at al actualizar |
PUT /api/incidentes/${incidenteId} | 200 status es En revisión, update_at es un string y updated_by es el usuario con ID=9992 | 200 status=´En revisión´, update_at es una fecha en formato string y updated_by=9992 |
PUT /:id con status "Firmado" debería asignar signed_by_user_id y signed_at |
PUT /api/incidentes/${incidenteId} | 200 status es Firmado signed_at es un string y * signed_by_user_id* es el usuario con ID=9992 | 200 status=´Firmado´, signed_at es una fecha en formato string y signed_by_user_id=9992 |
PUT /:id con status "Resuelto" hecho por técnico debería asignar finished_by y finished_at |
PUT /api/incidentes/${incidenteId} | 200 status es Resuelto, finished_at es un string y finished_by es el usuario con ID=10001 | 200 status=´Resuelto´, finished_at es una fecha en formato string y finished_by=10001 |
11 nuevas pruebas unitarias de la API de usuarios
| Caso de prueba | Datos de entrada (método+ruta+body) | Resultado esperado | Resultado obtenido |
|---|---|---|---|
GET / debería devolver lista de usuarios |
GET /api/users | 200 y una lista de usuarios | 200 y la lista correctamente |
GET /:id debería devolver un usuario existente |
GET /api/users/{usuario} | 200 y la información del usuario con ID=9991 | 200 y toda la información del usuario |
GET /username/:username debería devolver usuario por username |
GET /api/users/username/{nombre de usuario} | 200 y la información del usuario con username=testuser1 | 200 e información parcial del usuario |
GET /username/:username debería devolver 404 si no existe |
GET /api/users/username/{username inexistente en BD} | 404 Página No encontrada | 404 Página No encontrada |
POST / debería crear un nuevo usuario correctamente |
POST /api/users (body con info de usuario) | 201 Creado | 201 Creado |
POST / debería fallar si falta username |
POST /api/users (body con email y contraseña) | 400 Bad Request | 400 Bad Request |
POST / debería fallar si el username o email ya existen |
POST /api/users (body con username ya usado) | 409 Conflict | 409 Conflict |
PUT /:id debería actualizar un usuario |
PUT /api/users{ID} | 200 | 200 |
PUT /:id debería devolver 404 si no existe |
PUT /api/users/{ID inexistente} | 404 Página No encontrada | 404 Página No encontrada |
DELETE /:id debería eliminar un usuario |
DELETE /api/users/{ID} | 204 Sin Contenido y se elimina el usuario en BD | 204 Sin Contenido y se elimina correctamente |
DELETE /:id debería devolver 404 si el usuario no existe |
DELETE /api/users/{ID inexistente} | 404 Página No encontrada | 404 Página No encontrada |
5 nuevas pruebas unitarias de la API de login
| Caso de prueba | Datos de entrada (método+ruta+body) | Resultado esperado | Resultado obtenido |
|---|---|---|---|
POST /login debería autenticar con credenciales válidas |
POST /login (body: usuario y clave) | 200, el body contiene el token y la información del usuario | 200 el body contiene toda la información |
POST /login debería fallar con contraseña incorrecta |
POST /login (body: usuario y clave erronea) | 401 No autorizado | 401 No autorizado |
POST /login debería fallar con usuario no existente |
POST /login (body: usuario erroneo y clave) | 401 No autorizado | 401 No autorizado |
POST /login debería fallar si faltan campos |
POST /login (body: solo clave) | 400 Bad Request | 400 Bad Request |
POST /logout debería limpiar la cookie |
POST /logout | 200 | 200 |
La documentación de las pruebas realizadas en Selenium para la entrega 3 son las siguientes:
Pruebas Selenium
Se agregarán las pruebas próximamente, se pueden revisar en el codigo