Se realizaron pruebas sobre los principales escenarios de los endpoints desarrollados en el backend de Conectados. No se ejecutó el CRUD completo de cada entidad. Solo se validaron los endpoints utilizados directamente en los flujos funcionales implementados durante la Entrega 1 (por ejemplo: registro de usuarios, creación de servicios y agendamiento de citas).

Las pruebas fueron realizadas utilizando Postman, permitiendo enviar solicitudes HTTP y verificar las respuestas esperadas del sistema frente a distintos casos de entrada.

A continuación se detallan los casos evaluados, junto con sus resultados y observaciones:

• Entrada: nombre, correo, contraseña
• Rol seleccionado: BUSCADOR
• Resultado esperado: 200 OK y el usuario registrado correctamente.
• Resultado obtenido: 200 OK
• Observación: El usuario fue registrado correctamente con el rol BUSCADOR y sin errores.

• Entrada: nombre, correo, contraseña, zona, categoría, disponibilidad, descripción
• Rol seleccionado: PRESTADOR
• Resultado esperado: 200 OK
• Resultado obtenido: 200 OK
• Observación: El usuario fue registrado correctamente con los campos adicionales asociados a su rol.

• Entrada: correo ya registrado previamente
• Resultado esperado: 409 Conflict
• Resultado obtenido (inicialmente): 200 OK
• Observación inicial: El sistema permitía crear múltiples usuarios con el mismo correo electrónico, lo cual representa una violación del principio de unicidad en la identificación de usuarios. Esto generaba inconsistencias y ambigüedad en el login, asignación de servicios, y trazabilidad de acciones del usuario.

Se modificó la lógica dentro del método registrarUsuario del servicio correspondiente, agregando una validación explícita al inicio del proceso:

Optional<Usuario> existente = usuarioRepository.findByCorreo(dto.getCorreo());
if (existente.isPresent()) {
    throw new RuntimeException("Ya existe una cuenta con este correo");
}

Esta verificación consulta al repositorio (usuarioRepository) si ya existe un usuario con el mismo correo. En caso afirmativo, lanza una excepción de forma inmediata, impidiendo que continúe el registro y devolviendo un mensaje claro al cliente.

Esta solución asegura que cada correo electrónico sea único dentro del sistema, fortaleciendo la seguridad, consistencia de la base de datos y la integridad del modelo de usuarios.

• Resultado actual: 409 Conflict

• Mensaje devuelto:

  {
    "message": "Ya existe una cuenta con este correo"
  }

• Estado: Corregido exitosamente. La verificación de unicidad quedó integrada dentro del flujo de negocio.

• Entrada: ID válido de un usuario existente (/api/usuarios/id/{id})
• Resultado esperado: 200 OK y detalle completo del usuario
• Resultado obtenido: 200 OK
• Observación: Se obtuvo correctamente el detalle del usuario según el ID consultado.

• Entrada: nombre, precio, zona de atención, descripción, imagen, categoría, ID del prestador
• Resultado esperado: 200 OK
• Resultado obtenido: 200 OK
• Observación: El servicio fue creado correctamente y quedó asociado al prestador correspondiente. Se validaron todos los campos obligatorios.

• Entrada: nombre, precio actualizado, zona de atención, categoría, descripción, foto
• Resultado esperado: Servicio actualizado correctamente con el nuevo precio.
• Resultado obtenido: 200 OK
• Observación:
  El backend actualiza solo campos específicos (nombre, precio, zonaAtencion, categoria, foto, descripcion). Otros datos como id, prestador o resenas no deben enviarse.

• Entrada: ID del servicio a eliminar (/api/servicios/eliminar/{id})
• Resultado esperado: 204 sin contenido y el servicio con ID 4 es eliminado correctamente del sistema.
• Resultado obtenido: 204 No Content
• Observación: El servicio fue eliminado correctamente. La respuesta '204' confirma la eliminación sin necesidad de retornar contenido.

• Entrada: ID del servicio (/api/servicios/{ID})
• Resultado esperado: 200 OK con el detalle completo del servicio solicitado
• Resultado obtenido: 200 OK
• Observación: Se obtuvo correctamente el servicio con todos sus atributos. La imagen se devuelve en formato base64 como string en el campo foto.

• Entrada: ID del servicio (/api/servicios/{ID})
• Resultado esperado: 200 OK con el detalle completo del servicio solicitado
• Resultado obtenido: 200 OK
• Observación: Se obtuvo correctamente el servicio con todos sus atributos. La imagen se devuelve en formato base64 como string en el campo foto.

• Entrada: ID del prestador (/api/servicios/prestador/{ID})
• Resultado esperado: 200 OK con listado de servicios asociados al prestador
• Resultado obtenido: 200 OK
• Observación: Se recuperaron correctamente los servicios registrados por el prestador con ID 2. En este caso, el servicio listado incluye imagen en formato base64.

• Entrada: comentario, fecha, valoración, ID del buscador, ID del prestador, ID del servicio
• Resultado esperado: 200 OK con los datos de la reseña recién creada
• Resultado obtenido: 200 OK
• Observación: La reseña fue registrada exitosamente y quedó asociada correctamente al buscador, prestador y servicio indicados. El nombre del buscador también fue devuelto en la respuesta para referencia.