|
1 | | -# Proyecto de Pruebas con Cypress |
| 1 | +# Proyecto de Pruebas con Cypress - Automatización de API Mitte |
2 | 2 |
|
3 | | -Este proyecto utiliza Cypress para realizar pruebas en una aplicación web y se conecta a una base de datos Oracle utilizando la biblioteca `oracledb`. También se utiliza `dotenv` para cargar las variables de entorno desde un archivo `.env`, `ajv` para realizar comparativas de esquemas de las respuestas en formato `.json` y los valores obtenidos del consumo API, y `cypress-mochawesome-reporter` para generar reportes de ejecución. |
| 3 | +Este proyecto consiste en la automatización de pruebas para una API encargada de la gestión de entradas, salidas y pagos de un parqueadero. Esta aplicación se comunica directamente con el autorizador de accesos para validar las transacciones. |
4 | 4 |
|
5 | | -## Instalación |
| 5 | +## Estructura del Proyecto |
6 | 6 |
|
7 | | -1. Clona este repositorio en tu máquina local. |
| 7 | +El proyecto sigue una estructura modular para facilitar el mantenimiento y la escalabilidad: |
8 | 8 |
|
9 | | -2. Abre una terminal y navega hasta la carpeta del proyecto. |
| 9 | +- **`cypress/e2e/`**: Contiene los archivos de prueba (`.cy.js`) que definen los escenarios y casos de prueba (bloques `it`). |
10 | 10 |
|
11 | | -3. Ejecuta el siguiente comando para instalar todas las dependencias: |
| 11 | +- **`cypress/support//`**: Carpeta principal para la lógica de soporte: |
12 | 12 |
|
13 | | -```bash |
14 | | - npm install |
15 | | -``` |
| 13 | + - **`assertions/`**: Contiene las validaciones personalizadas (Asserts) para verificar respuestas de API y estados de base de datos. |
16 | 14 |
|
17 | | -4. Renombra el archivo `.env.template` a `.env` y actualiza las variables de entorno con los valores correspondientes para la conexión a la base de datos Oracle. |
| 15 | + - **`page_objects//`** (Services): Contiene los objetos que encapsulan las solicitudes de envío a la API (lectura/escritura). |
18 | 16 |
|
19 | | -## Ejecución de Pruebas |
| 17 | + - **`utils/`**: Generadores de datos (Data Generators) y funciones auxiliares para las pruebas. |
20 | 18 |
|
21 | | -1. Para abrir Cypress en modo de interfaz de usuario, ejecuta el siguiente comando: |
22 | | -```bash |
23 | | - npx cypress open |
24 | | -``` |
25 | | -O alternativamente puedes usar el comando personalizado. |
26 | | -```bash |
27 | | - npm run cy:open |
28 | | -``` |
| 19 | + - **`constants/`**: Definición de constantes del proyecto, como nombres campos de API y mensajes de error. |
| 20 | + |
| 21 | + - **`commands.js`**: Comandos personalizados de Cypress (opcional). |
| 22 | + |
| 23 | +## Instalación |
29 | 24 |
|
30 | | - Esto abrirá la interfaz de usuario de Cypress, donde podrás seleccionar y ejecutar las pruebas manualmente. |
| 25 | +Sigue estos pasos para instalar y configurar el proyecto en tu entorno local: |
31 | 26 |
|
32 | | -2. Para ejecutar las pruebas en modo de línea de comandos, ejecuta el siguiente comando: |
| 27 | +1. **Clonar el repositorio** (si aplica) o navegar a la carpeta del proyecto. |
| 28 | +2. **Instalar dependencias**: |
| 29 | + Asegúrate de tener [Node.js](https://nodejs.org/) instalado y ejecuta el siguiente comando en la raíz del proyecto: |
| 30 | + ```bash |
| 31 | + npm install |
| 32 | + ``` |
| 33 | + |
| 34 | +## Ejecución de Pruebas |
| 35 | + |
| 36 | +Puedes ejecutar las pruebas de tres maneras diferentes según tus necesidades: |
| 37 | + |
| 38 | +### 1. Ejecución en el Navegador (Interfaz de Usuario de Cypress) |
| 39 | +Para abrir el test runner de Cypress y ejecutar pruebas de forma interactiva: |
33 | 40 | ```bash |
34 | | - npm run test |
| 41 | +npm run cy:open |
35 | 42 | ``` |
36 | | - Esto ejecutará las pruebas automáticamente y mostrará el resultado en la terminal. |
37 | 43 |
|
38 | | -3. Para ejecutar las pruebas con Allure habilitado: |
| 44 | +### 2. Ejecución por Línea de Comandos (Modo Headless) |
| 45 | +Para ejecutar todas las pruebas en segundo plano desde la terminal: |
39 | 46 | ```bash |
40 | | - npm npm run test:report |
| 47 | +npm run test |
41 | 48 | ``` |
42 | 49 |
|
| 50 | +### 3. Ejecución con Reportes Allure |
| 51 | +Para generar y visualizar los reportes detallados de Allure: |
| 52 | + |
| 53 | +- **Ejecutar pruebas capturando datos para Allure**: |
| 54 | + ```bash |
| 55 | + npm run test:allure |
| 56 | + ``` |
| 57 | +- **Generar el reporte de Allure**: |
| 58 | + ```bash |
| 59 | + npm run allure:report |
| 60 | + ``` |
| 61 | +- **Abrir el reporte generado**: |
| 62 | + ```bash |
| 63 | + npm run allure:open |
| 64 | + ``` |
| 65 | +- **Limpiar reportes anteriores y ejecutar todo el flujo**: |
| 66 | + ```bash |
| 67 | + npm run test:report |
| 68 | + ``` |
| 69 | + |
43 | 70 | ## Cambio de Variables de Entorno |
44 | 71 |
|
45 | | -El archivo `.env` contiene las variables de entorno necesarias para la conexión a la base de datos Oracle. Para cambiar estas variables, sigue estos pasos: |
| 72 | +El proyecto utiliza variables de entorno para gestionar credenciales y conexiones. Debes configurar un archivo `.env` en la raíz del proyecto con la siguiente estructura: |
46 | 73 |
|
47 | | -1. Abre el archivo `.env` en un editor de texto. |
| 74 | +```env |
| 75 | +# Configuración de Base de Datos (Oracle) |
| 76 | +DB_USER=tu_usuario |
| 77 | +DB_PASSWORD=tu_contraseña |
| 78 | +DB_CONNECT_STRING=tu_string_de_conexion |
48 | 79 |
|
49 | | -2. Actualiza los valores de las variables `DB_USER`, `DB_PASSWORD` y `DB_CONNECT_STRING` con los valores correctos para tu entorno de base de datos. |
| 80 | +# Autenticación Cognito |
| 81 | +COGNITO_USERNAME=tu_usuario_cognito |
| 82 | +COGNITO_PASSWORD=tu_password_cognito |
| 83 | +COGNITO_CLIENT_ID=tu_client_id |
50 | 84 | ``` |
51 | | - DB_USER=usuario |
52 | | - DB_PASSWORD=clave |
53 | | - DB_CONNECT_STRING=oracleDbHost |
54 | | -``` |
55 | | - |
56 | 85 |
|
57 | | -3. Guarda los cambios en el archivo. |
| 86 | +--- |
58 | 87 |
|
59 | | -## Reporte de Ejecución |
| 88 | +## Documentación de Pruebas (Escenarios de Automatización) |
60 | 89 |
|
61 | | -Después de ejecutar las pruebas, se generará un reporte utilizando la biblioteca `cypress-mochawesome-reporter`. |
62 | | -Podrá acceder al reporte de pruebas en la ruta [cypress/reports/html/index.html](cypress/reports/html/index.hml) desde la raíz del proyecto. |
| 90 | +### Gestión de Entradas (`CreateEntryStep.cy.js` y `CreateEntryValidation.cy.js`) |
63 | 91 |
|
64 | | -## Recomendación para utilizar ajv para validación de esquemas |
| 92 | +- **Entrada Exitosa**: Valida la entrada exitosa de un vehículo a un parqueadero Mitte con el servicio de Flypass, verificando tanto la respuesta de la API como el registro en la base de datos. |
65 | 93 |
|
66 | | -Cuando estamos validando la estructura de las respuestas que se generan a partir del llamado de un API, se deben crear archivos de referencia que indiquen la obligatoriedad de los campos que recibimos, tipos de datos esperados, y estructura de la información, de la siguiente forma: |
| 94 | +- **Entrada Rechazada**: Valida que la entrada sea rechazada cuando la placa no está autorizada. |
67 | 95 |
|
68 | | -Imaginemos que al registrar un usuario por medio de un método POST, obtenemos la siguiente estructura: |
| 96 | +- **Validaciones de Contrato**: |
| 97 | + - Validar que retorne `400 Bad Request` si faltan campos obligatorios como `sessionId`, `localIdentifier`, `actualStart` o `placeId`. |
| 98 | + - Validar que retorne `400` cuando los campos tienen valores inválidos (Nulos, Vacíos o formatos de fecha incorrectos). |
69 | 99 |
|
70 | | -```json |
71 | | -{ |
72 | | - "id": 4, |
73 | | - "token": "QpwL5tke4Pnpja7X4" |
74 | | -} |
75 | | -``` |
| 100 | +### Gestión de Salidas (`CreateExitStep.cy.js` y `CreateExitValidation.cy.js`) |
76 | 101 |
|
77 | | -Queremos validar la obligatoriedad del cumplimiento de su esquema, donde id, y token, son atributos obligatorios, y cada uno de ellos tienen tipos de datos `integer`, y `string` respectivamente, para lograrlo, debemos definir la estructura de la siguiente manera: |
78 | | - |
79 | | -```json |
80 | | -{ |
81 | | - "type": "object", |
82 | | - "properties": { |
83 | | - "id": { |
84 | | - "type": "integer" |
85 | | - }, |
86 | | - "token": { |
87 | | - "type": "string" |
88 | | - } |
89 | | - }, |
90 | | - "required": [ |
91 | | - "id", |
92 | | - "token" |
93 | | - ] |
94 | | -} |
95 | | -``` |
| 102 | +- **Salida Exitosa**: Valida la salida de un vehículo, asegurando que se procese correctamente en el sistema y se refleje en la base de datos. |
96 | 103 |
|
97 | | -Allí es donde entra en juego la validación que nos permite realizar la librería `ajv` respecto al tipo de datos y el cumplimiento del contrato (o esquema) de la respuesta obtenida. |
| 104 | +- **Salida Rechazada**: Valida que la salida sea rechazada por placa no autorizada. |
98 | 105 |
|
99 | | -Puedes hacer uso de herramientas que nos permitan crear los esquemas de forma automática como por ejemplo: https://www.liquid-technologies.com/online-json-to-schema-converter |
| 106 | +- **Flujo Completo (End-to-End)**: Registra una entrada exitosa y posteriormente una salida exitosa para el mismo vehículo/sesión. |
100 | 107 |
|
| 108 | +- **Validaciones de Contrato**: |
| 109 | + - Validar que retorne `400 Bad Request` si faltan campos obligatorios como `sessionId`, `placeId`, `actualStart`, `currency` o `actualEnd`. |
0 commit comments