Historia de Usuario: Visualizar Candidatos (Backend)

dmsierra11 commented 3 months ago

Historia de Usuario: Visualizar Candidatos

Descripción

Como reclutador, quiero visualizar una lista de todos los candidatos y acceder a los detalles individuales, para poder revisar y evaluar la información de cada candidato de manera eficiente.

Criterios de Aceptación

Acceso a la Lista de Candidatos
- El reclutador debe poder acceder a una página que muestre una lista completa de todos los candidatos registrados en el sistema.
- La lista debe mostrar los siguientes campos por defecto: Nombre, Apellido, Correo Electrónico y Teléfono.
Visualización Detallada de Candidatos
- El reclutador debe poder hacer clic en cualquier candidato de la lista para ver una página con información detallada.
- La página detallada debe incluir: Nombre, Apellido, Correo Electrónico, Teléfono, Dirección (si está disponible), Educación, Experiencia Laboral y CV.
Interfaz de Usuario Intuitiva
- La lista de candidatos debe ser fácil de navegar con una interfaz de usuario clara y amigable.
- Debe haber un botón o enlace claramente visible para acceder a los detalles de cada candidato.
Filtrado y Búsqueda
- El reclutador debe poder buscar candidatos por nombre, apellido, o correo electrónico.
- Debe haber opciones de filtro para refinar la lista de candidatos por criterios como experiencia laboral, educación, etc.
Ordenación
- La lista de candidatos debe poder ordenarse por nombre, apellido, o cualquier otro campo relevante.
Responsividad
- La interfaz debe ser completamente responsiva y accesible desde dispositivos móviles y de escritorio.

Dependencias

Implementación de los módulos de gestión de candidatos para asegurar que los datos sean precisos y estén actualizados.

Notas Adicionales

Considerar la integración con herramientas de análisis para recolectar datos de uso y mejorar la funcionalidad en futuras iteraciones.
Asegurar que todas las operaciones cumplen con las regulaciones de protección de datos (GDPR, CCPA, etc.).

dmsierra11 commented 3 months ago

Prompt

Genera un plan de pruebas unitarias para el backend de esta historia de usuario:

Historia de Usuario: Visualizar Candidatos Descripción Como reclutador, quiero visualizar una lista de todos los candidatos y acceder a los detalles individuales, para poder revisar y evaluar la información de cada candidato de manera eficiente.

Criterios de Aceptación Acceso a la Lista de Candidatos

El reclutador debe poder acceder a una página que muestre una lista completa de todos los candidatos registrados en el sistema. La lista debe mostrar los siguientes campos por defecto: Nombre, Apellido, Correo Electrónico y Teléfono. Visualización Detallada de Candidatos

El reclutador debe poder hacer clic en cualquier candidato de la lista para ver una página con información detallada. La página detallada debe incluir: Nombre, Apellido, Correo Electrónico, Teléfono, Dirección (si está disponible), Educación, Experiencia Laboral y CV. Interfaz de Usuario Intuitiva

La lista de candidatos debe ser fácil de navegar con una interfaz de usuario clara y amigable. Debe haber un botón o enlace claramente visible para acceder a los detalles de cada candidato. Filtrado y Búsqueda

El reclutador debe poder buscar candidatos por nombre, apellido, o correo electrónico. Debe haber opciones de filtro para refinar la lista de candidatos por criterios como experiencia laboral, educación, etc. Ordenación

La lista de candidatos debe poder ordenarse por nombre, apellido, o cualquier otro campo relevante. Responsividad

La interfaz debe ser completamente responsiva y accesible desde dispositivos móviles y de escritorio. Dependencias Implementación de los módulos de gestión de candidatos para asegurar que los datos sean precisos y estén actualizados. Notas Adicionales Considerar la integración con herramientas de análisis para recolectar datos de uso y mejorar la funcionalidad en futuras iteraciones. Asegurar que todas las operaciones cumplen con las regulaciones de protección de datos (GDPR, CCPA, etc.).

Contexto del proyecto: @backend

dmsierra11 commented 3 months ago

Genera las pruebas unitarias de esta historia de usuario. Vamos a utilizar TS Jest (ya está configurado). Antes de empezar, dimé lo que vas a hacer y hazme toda las preguntas que necesites, no escribas código aún.

Plan de Pruebas Unitarias para la Historia de Usuario "Visualizar Candidatos"

Visión General

Para asegurar que la funcionalidad del backend para la historia de usuario "Visualizar Candidatos" cumpla con los criterios de aceptación, desarrollaremos un plan de pruebas unitarias exhaustivo. Este plan cubrirá las funcionalidades principales, incluyendo la recuperación de una lista de candidatos, el acceso a información detallada de los candidatos y asegurando que las interacciones de la interfaz de usuario sean manejadas correctamente por el backend.

Escenarios de Prueba

Recuperar Lista de Candidatos Objetivo: Verificar que el sistema puede recuperar y retornar una lista de todos los candidatos con los campos requeridos (Nombre, Apellido, Correo Electrónico y Teléfono). Pruebas: Recuperar con éxito una lista completa de candidatos. Retornar una lista vacía cuando no hay candidatos disponibles. Manejar adecuadamente los errores de base de datos (por ejemplo, problemas de conexión).
Acceso a Información Detallada del Candidato Objetivo: Asegurar que el backend puede recuperar y retornar información detallada de un candidato específico. Pruebas: Recuperar con éxito la información detallada cuando se proporciona un ID de candidato válido. Retornar un error o nulo cuando se usa un ID de candidato inválido o inexistente. Manejar de manera adecuada los errores de conexión a la base de datos.
Filtrado y Búsqueda Objetivo: Probar la capacidad del backend para filtrar y buscar en la lista de candidatos basándose en criterios proporcionados. Pruebas: Filtrar correctamente los candidatos por varios atributos como educación y experiencia laboral. Permitir la búsqueda por nombre, apellido o correo electrónico y retornar resultados precisos. Asegurar que los mecanismos de búsqueda y filtrado sean seguros contra inyecciones SQL.

Utiliza las mejores prácticas de testing como AAA y Parametrización. Utiliza patrones de TDD como Red-Green-Refactor y Fake-til-you-make-it

Contexto: Capa de Servicio @candidateService.ts Esta capa debe manejar la lógica de negocio e interactuar con la base de datos u otros servicios. Debe ser probada por su funcionalidad de manera independiente del marco web, centrándose en su capacidad para realizar operaciones correctamente con los datos proporcionados.

Capa de Controlador @candidateController.ts Esta capa gestiona el ciclo de solicitud y respuesta HTTP, delegando la lógica de negocio a la capa de servicio y decidiendo qué respuestas HTTP enviar. Las pruebas aquí implicarían verificar si se devuelven los códigos de estado y las salidas correctas para varias entradas.

Rutas @candidateRoutes.ts Esta capa configura los puntos de acceso y los vincula a funciones específicas del controlador. Las pruebas de rutas típicamente implican verificar si se llama al controlador correcto y si las rutas están aseguradas o tienen el middleware adecuado.

Modelo de datos @schema.prisma

Definición API @api-spec.yaml

Contexto del proyecto: @README.md

dmsierra11 commented 3 months ago

Tal vez debamos agregar este contexto al README del proyecto:

Arquitectura del Proyecto

Capa de Servicio (@candidateService.ts)

Maneja la lógica de negocio e interactúa con la base de datos u otros servicios. Esta capa debe ser probada de manera independiente del marco web, asegurando que las operaciones se realicen correctamente con los datos proporcionados.

Capa de Controlador (@candidateController.ts)

Gestiona el ciclo de solicitud y respuesta HTTP. Delegar la lógica de negocio a la capa de servicio y decide qué respuestas HTTP enviar. Las pruebas en esta capa deben verificar los códigos de estado y las respuestas correctas para varias entradas.

Rutas (@candidateRoutes.ts)

Configura los puntos de acceso y los vincula a funciones específicas del controlador. Las pruebas de rutas deben asegurarse de que se llame al controlador correcto y que las rutas estén aseguradas o tengan el middleware adecuado.

Modelo de Datos (@schema.prisma)

Define la estructura de los datos y las relaciones en la base de datos utilizando Prisma.

Definición API (@api-spec.yaml)

Contiene la especificación de la API, detallando los endpoints disponibles y sus respectivos esquemas de solicitud y respuesta.

dmsierra11 commented 3 months ago

Antes de empezar, vamos a aclarar los mocks que necesitamos

dmsierra11 commented 3 months ago

Prompt

Modelos

Basándonos en @Candidate, vamos a implementar las pruebas de @Education.ts @Resume.ts y @WorkExperience.ts Contexto del proyecto: @README.md Modelo de datos: @schema.prisma Definición API: @api-spec.yaml

dmsierra11 commented 3 months ago

Recomendación

Implementa los tests capa por capa Ejemplo: Bien, procedamos con la capa @services

dmsierra11 commented 3 months ago

Mocks

Para asegurarnos mejores resultados en la configuración de los mocks lo mejor es que indaguemos más y demos instrucciones más específicas

Ejemplo

En este ejemplo estaba teniendo un error de prisma client en mi candidateController.

Prompt No creo que deba preocuparme por Prisma en mi @candidateController.ts . No deberíamos mockear getCandidate para siempre retornar un @Candidate.ts ?

dmsierra11 commented 3 months ago

Mocks

Podemos agregar al prompt algunos ejemplos de las prácticas de mock que quieres implementar. Para esto puedes utilizar ChatGPT o el propio cursor para entender las mejores prácticas y decidir cual quieres implementar.

Ejemplo:

De aquí podemos sacar algo que podríamos incluir en nuestro prompt inicial

dmsierra11 commented 3 months ago

Types

Importante definir los types de nuestros models cuanto antes para obtener mejores resultados en la autogeneración de código

interface EducationInput {
    institution: string;
    title: string;
    startDate: Date; // Changed from string to Date for consistency with Prisma type
    endDate?: Date;  // Changed from string to Date for consistency with Prisma type
}

interface WorkExperienceInput {
    company: string;
    position: string;
    description?: string;
    startDate: Date; // Changed from string to Date for consistency with Prisma type
    endDate?: Date;  // Changed from string to Date for consistency with Prisma type
}

interface ResumeInput {
    filePath: string;
    fileType: string;
}

interface CandidateInput {
    firstName: string;
    lastName: string;
    email: string;
    phone?: string;
    address?: string;
    educations?: EducationInput[];
    workExperiences?: WorkExperienceInput[];
    cv?: ResumeInput;
}

dmsierra11 / my-ui-library