Plan de Pruebas Unitarias y de Aceptación — FaCyT Events

Este documento detalla la lista completa de pruebas y casos de uso necesarios para certificar la estabilidad, seguridad y correcto funcionamiento de todos los módulos y flujos de FaCyT Events.

🔑 Credenciales de Prueba (Test Credentials)

Para la ejecución de este plan de pruebas en el entorno local o de producción, utilice las siguientes cuentas preconfiguradas con diferentes roles y niveles de acceso (RBAC):

1. Rol: Coordinador (Administrador General)

• Nombre: Administrador Coordinador FaCyT
• Cédula: V-10000001
• Correo Electrónico: admin@facyt.uc.edu.ve
• Contraseña: FaCyT2026!
• Privilegios: Gestión total de espacios (isActive, crear, editar), aprobación de solicitudes, resolución de colisiones y visualización de reportes globales.

2. Rol: Organizador (Profesor / Dependencia)

• Nombre: Organizador de Pruebas
• Cédula: V-10000002
• Correo Electrónico: organizador@facyt.uc.edu.ve
• Contraseña: Organizador2026!
• Privilegios: Crear solicitudes de eventos, gestionar y visualizar únicamente a los moderadores creados por sí mismo (createdById).

3. Rol: Moderador (Auxiliar / Pasante)

• Nombre: Moderador de Pruebas
• Cédula: V-10000003
• Correo Electrónico: moderador@facyt.uc.edu.ve
• Contraseña: Moderador2026!
• Privilegios: Aceptar/rechazar solicitudes de moderación, control de asistencia QR continuo y búsqueda manual de participantes registrados en eventos asignados.

🔑 1. Autenticación y Gestión de Usuarios (auth y users)

Pruebas de Registro y Login

• [ ] Registro Exitoso: Crear una cuenta pública desde /register con datos válidos. Confirmar que guarda la contraseña cifrada con Bcrypt (12 rondas) y redirige al login.
• [ ] Restricción de Correo Duplicado: Intentar registrar un correo ya existente. Debe retornar ConflictException (HTTP 409).
• [ ] Restricción de Cédula Duplicada: Intentar registrar una cédula ya existente. Debe retornar ConflictException (HTTP 409).
• [ ] Login Exitoso: Iniciar sesión con credenciales correctas. Confirmar que retorna un JWT firmado y que el frontend guarda la sesión.
• [ ] Login Erróneo: Intentar iniciar sesión con contraseña incorrecta. Debe retornar Unauthorized (HTTP 401).

Pruebas de Perfil y Seguridad

• [ ] Cambio de Contraseña: Cambiar la contraseña desde el panel de perfil. Validar que la contraseña vieja sea correcta y que la nueva permita iniciar sesión en el siguiente intento.
• [ ] Actualización de Perfil: Editar el nombre y la suscripción de notificaciones. Confirmar que se guarda en PostgreSQL y se actualiza reactivamente la sesión en el navegador.

Pruebas de Jerarquía y Registro de Usuarios (RBAC)

• [ ] Creación por Coordinador: Iniciar sesión como Coordinador y registrar a un Organizador, a un Moderador y a otro Coordinador. Todos deben crearse con éxito.
• [ ] Creación por Organizador: Iniciar sesión como Organizador e intentar crear un Moderador. Debe registrarse con éxito.
• [ ] Bloqueo a Organizador: Como Organizador, intentar registrar un Coordinador u otro Organizador. El backend debe lanzar ForbiddenException (HTTP 403).
• [ ] Filtro de Creador: Como Organizador, ir a la sección de usuarios y verificar que solo se muestran los moderadores creados bajo su createdById (no los creados por otros organizadores o coordinadores).

🏛️ 2. Módulo de Espacios (spaces)

• [ ] Creación de Espacio: Crear un espacio con nombre, ubicación, aforo (capacidad) y direcciones de llegada.
• [ ] Control de Aforo Lógico: Intentar crear un espacio con capacidad negativa o de cero. Debe ser bloqueado por los validadores del DTO.
• [ ] Edición de Espacio: Modificar la capacidad o ubicación de un espacio existente.
• [ ] Filtro de Disponibilidad (`isActive`): Cambiar el estado de un espacio a inactivo (isActive = false). Confirmar que este espacio deja de aparecer en el formulario de solicitud de evento del Organizador.

📅 3. Solicitud y Gestión de Eventos (events)

Validaciones Básicas

• [ ] Consistencia de Fechas: Crear un evento donde startTime sea mayor o igual que endTime (ej: inicio a las 10:00 AM y fin a las 9:00 AM). Debe retornar BadRequestException (HTTP 400).

Pruebas de la "Regla de Oro" de Colisiones

Para validar el algoritmo de solapamiento en el mismo space_id:

• [ ] Caso de Uso 1 (Choque por el fin): Evento A aprobado de 08:00 a 10:00. Solicitar Evento B de 09:00 a 11:00. Resultado esperado: Bloqueado por colisión.
• [ ] Caso de Uso 2 (Choque por el inicio): Evento A aprobado de 08:00 a 10:00. Solicitar Evento B de 07:00 a 09:00. Resultado esperado: Bloqueado por colisión.
• [ ] Caso de Uso 3 (Choque de inclusión total): Evento A aprobado de 08:00 a 10:00. Solicitar Evento B de 08:30 a 09:30. Resultado esperado: Bloqueado por colisión.
• [ ] Caso de Uso 4 (Choque envolvente): Evento A aprobado de 08:00 a 10:00. Solicitar Evento B de 07:00 a 11:00. Resultado esperado: Bloqueado por colisión.
• [ ] Caso de Uso 5 (Límites Adyacentes - Sin Choque): Evento A aprobado de 08:00 a 10:00. Solicitar Evento B de 10:00 a 12:00. Resultado esperado: Solicitud exitosa (las fronteras exactas de tiempo no colisionan).
• [ ] Caso de Uso 6 (Espacios Distintos - Sin Choque): Solicitar Evento B de 09:00 a 11:00 en el *Espacio 2* mientras el Evento A está aprobado en el *Espacio 1* en el mismo horario. Resultado esperado: Solicitud exitosa.
• [ ] Caso de Uso 7 (Estados Inactivos - Sin Choque): Solicitar Evento B de 09:00 a 11:00 en el *Espacio 1* cuando el Evento A en ese mismo horario está en estado rechazado, cancelado o realizado. Resultado esperado: Solicitud exitosa.
• [ ] Caso de Uso 8 (Auto-exclusión en Edición): Modificar la descripción de un evento propio ya aprobado sin cambiar su horario o espacio. Confirmar que el sistema permite la edición sin acusar colisión consigo mismo.

🤝 4. Asignación y Moderación (moderator-requests)

• [ ] Envío de Invitación: Como Organizador del evento, enviar una invitación de moderación a un usuario con rol Moderador.
• [ ] Bloqueo de Intrusos: Como Organizador A, intentar invitar un moderador a un evento creado por el Organizador B. Debe lanzar ForbiddenException (HTTP 403).
• [ ] Recepción de Invitación: Iniciar sesión como el Moderador invitado y verificar que la solicitud aparece como "Pendiente" en el dashboard.
• [ ] Rechazo de Invitación: Hacer clic en "Rechazar". El evento no debe aparecer en la lista de eventos del moderador.
• [ ] Aceptación de Invitación: Hacer clic en "Aceptar". El estado de la invitación cambia a aceptado y el evento se indexa en la lista de eventos a auditar del Moderador.
• [ ] Doble Invitación: Intentar invitar dos veces al mismo moderador al mismo evento. Debe retornar un error indicando que ya tiene una invitación en curso.

📝 5. Inscripciones y Control de Aforo (registrations)

• [ ] Inscripción Pública: Rellenar el formulario de inscripción a un evento aprobado. Validar que genera un registro en base de datos con un código QR único (UUID) en estado confirmado.
• [ ] Control de Aforo Máximo: Configurar un espacio con capacidad para 3 personas. Registrar a 3 participantes. Intentar registrar a un 4.º participante. Resultado esperado: BadRequestException (HTTP 400) informando aforo completo.
• [ ] Unicidad de Inscripción: Intentar inscribir a una persona con la misma cédula dos veces en el mismo evento. Debe retornar ConflictException (HTTP 409).

📸 6. Verificación de Asistencia por QR y Cédula

• [ ] Escaneo Exitoso de QR: Escanear el QR de un participante inscrito. Confirmar que cambia attended a true y guarda la fecha attendedAt.
• [ ] Escaneo Duplicado: Escanear el mismo QR por segunda vez. Debe mostrar una alerta: *"El participante ya registró su asistencia"*.
• [ ] QR de otro Evento: Escanear un QR que corresponde a una inscripción de otro evento diferente. Debe retornar error y denegar el acceso.
• [ ] Check-In Manual por Cédula: Buscar una cédula inscrita en la barra del Moderador y hacer clic en confirmar. Debe registrar la asistencia con éxito.
• [ ] Cédula no Inscrita: Buscar una cédula que no se registró al evento. Debe alertar: *"Participante no encontrado"*.
• [ ] Privilegios de Organizador: Iniciar sesión como Organizador y verificar que ahora tiene visible y funcional el panel de escáner QR y el listado de participantes para sus propios eventos.
• [ ] Seguridad del Moderador No Asignado: Intentar forzar una petición de check-in (PATCH /registrations/:id/attend) usando las credenciales de un moderador que no aceptó invitación para ese evento. Debe lanzar ForbiddenException (HTTP 403).

✉️ 7. Notificaciones Automáticas por Correo

*(Realizar estas pruebas verificando la bandeja de entrada real o la consola de logs en Resend)*

• [ ] Broadcast de Aprobación: Aprobar un evento solicitado. Validar que se envía un correo a todos los usuarios que tienen marcado receiveNotifications = true. Verificar que el correo utiliza copia oculta (BCC) para no revelar los emails de los destinatarios.
• [ ] Notificación de Cancelación: Cambiar el estado de un evento aprobado a cancelado. Validar que todos los inscritos confirmados reciben un correo de notificación de cancelación del evento.
• [ ] Notificación de Reprogramación: Modificar la fecha o el espacio de un evento aprobado. Validar que todos los inscritos confirmados reciben un correo indicando los nuevos datos del evento.

🤖 8. Tareas Programadas Automáticas (Cron Schedulers)

• [ ] Finalización Automática de Eventos: Crear un evento aprobado cuya fecha de fin (endTime) esté a 1 minuto en el futuro. Dejar pasar el tiempo. Al ejecutarse la verificación del backend (que corre cada 30 minutos o al reiniciar la aplicación), el estado del evento debe cambiar automáticamente a realizado.

🖼️ 9. Carga de Archivos e Imágenes (uploads)

• [ ] Subida de Portada de Evento: Crear un evento subiendo una imagen en el formulario. Verificar que en la previsualización local y en producción (VPS) la imagen carga de inmediato y no aparece como rota.
• [ ] Verificación de Rutas Dinámicas: Validar que al cambiar de entorno (local vs. producción), las imágenes resuelvan a través del helper getMediaUrl apuntando al dominio correcto (localhost:3001 o api.facyt-events.sunlessteam.com) y no queden enlaces locales hardcodeados en el servidor en producción.

📋 10. Pruebas de la Versión 1.4.0 (Nuevas Características)

Reprogramaciones y Rechazos

• [ ] Flujo de Reprogramación: Como Organizador, intentar modificar la fecha/hora/espacio de un evento en estado aprobado. Confirmar que se bloquea la edición directa, solicitando confirmación para generar una solicitud de reprogramación en estado pendiente.
• [ ] Detección Permisiva de Coincidencias: Intentar crear dos solicitudes independientes en estado solicitado para el mismo espacio y fecha. El sistema debe permitir que ambas existan de forma concurrente sin dar colisión horaria.
• [ ] Bloqueo por Aprobación: Como Coordinador, aprobar una de las solicitudes solapadas. Al intentar aprobar la otra, el backend debe rechazar la acción (HTTP 400 Bad Request) e informar de la colisión horaria.
• [ ] Notificación de Rechazo con Motivo: Como Coordinador, rechazar una solicitud de evento ingresando una justificación. Confirmar que el Organizador recibe un correo electrónico que detalla dicho motivo, y que en su panel del evento rechazado visualiza un banner explicativo que le permite volver a editar/solicitar el evento.

Correos con Códigos QR Integrados

• [ ] Comprobación de Imagen QR en Correos: Inscribirse en un evento y verificar en la bandeja de entrada que la imagen del QR no aparezca rota o como código base64 plano, sino como una imagen PNG renderizada correctamente gracias al adjunto con Content-ID (inline attachment).

Experiencia del Escáner QR de Asistencia

• [ ] Modal de Datos de Participante: Iniciar el escáner y leer el QR de un participante. Validar que la transmisión de la cámara se mantiene activa mientras se abre un modal flotante centralizado con la Nombre, Cédula y Correo.
• [ ] Confirmación Directa: Al presionar "Confirmar Entrada", el estado de asistencia del participante debe cambiar a presente, actualizar las estadísticas de fondo y cerrar el modal.
• [ ] Cooldown de Re-lectura: Tras confirmar o cerrar el modal del participante anterior, mantener la cámara apuntando al mismo código QR. Validar que el modal de "Registro Ya Procesado" no aparezca consecutivamente en bucle gracias a la ventana de cooldown de 4 segundos.

Advertencia de Capacidad (Aforo)

• [ ] Advertencia de Aforo: Intentar guardar un evento con un aforo estimado mayor a la capacidad física del espacio seleccionado. Validar que el frontend intercepta el submit mostrando un diálogo de advertencia interactivo (useConfirm), permitiendo al usuario decidir si continuar o cancelar la acción.

Ajustes Visuales, Filtros y Documentación (v1.4.0)

• [ ] Espaciado del Grid de Eventos: Verificar que tanto en la sección de Cartelera Universitaria como en el listado de todos los eventos de la página de inicio, las tarjetas de eventos utilicen un espaciado reducido de exactamente gap-3.
• [ ] Actualización Suave de Filtros: Interactuar con el buscador y filtros por salón en la página de inicio. Validar que los resultados y los encabezados correspondientes se actualicen de manera suave sin producir parpadeos visuales ni transiciones bruscas.
• [ ] Vistas Públicas de Documentación: Acceder a las rutas /documentacion/arquitectura, /documentacion/etica y /documentacion/pruebas. Verificar que carguen perfectamente todo el contenido, que se adapten a modo claro/oscuro y que incluyan un banner de presentación premium.
• [ ] Resaltado Activo en Navbar: Hacer clic en los enlaces del menú superior ("Inicio", "Arquitectura", "Ética y IA", "Guía de Pruebas"). Confirmar que la página activa se resalta con color y borde inferior visible tanto en escritorio como en la navegación móvil.