Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Giofelix/Proyecto-automatizacion-Empresa/llms.txt

Use this file to discover all available pages before exploring further.

automation-arqc distingue dos niveles de test según el alcance funcional que ejercitan. Los tests de componente prueban una sola pantalla del sistema (navegación, CRUD, validaciones de campo, paginación) y se ejecutan en paralelo de forma independiente. Los tests E2E reproducen un proceso real de usuario que cruza varias pantallas y estados — por ejemplo, crear un tercero, registrarlo como contribuyente, agregarle un establecimiento y presentar una declaración. La regla de clasificación es simple: ¿el test toca una sola URL de módulo? → componente. ¿Recorre varias pantallas para completar un proceso de negocio? → E2E en e2e/.

​
Nivel Componente vs E2E

AspectoComponenteE2E / Flujo
Carpetasuites/Reteica/suites/Reteica/e2e/
Nombre de archivo<modulo>.spec.jsflujo-<proceso>.spec.js
Tag obligatorio@componente@e2e
Pantallas involucradas1 solaVarias
Fixture principalpaginaAutenticadaestablecimientoData o similar
Modo de ejecuciónParalelo (por defecto)Serial dentro de cada describe
Ejemploterceros.spec.jsflujo-declaracion-contribuyente.spec.js

​
Estructura de carpetas

suites/
└── Reteica/
    ├── terceros.spec.js                              # @componente — CRUD de una pantalla
    ├── contribuyentes.spec.js                        # @componente — CRUD de una pantalla
    ├── conceptos.spec.js                             # @componente — CRUD de una pantalla
    ├── establecimientos.spec.js                      # @componente — CRUD subformulario
    └── e2e/
        └── flujo-declaracion-contribuyente.spec.js  # @e2e — proceso completo multi-pantalla

​
Sintaxis BDD con gherkin-lite

Todos los tests del proyecto usan gherkin-lite para estructurar los pasos del test en bloques given / when / then / and. Esto no afecta la ejecución de Playwright — cada bloque es simplemente una función async envuelta en un nombre de paso — pero hace que los reportes de Allure muestren los pasos con su semántica BDD y facilita la trazabilidad con los casos de Azure DevOps. El siguiente ejemplo real proviene de suites/Reteica/terceros.spec.js: 
const { given, when, then, and } = require('gherkin-lite');

test('TC-TER-01 — Navegación y carga del listado',
  { tag: '@smoke @terceros @reteica @tagprueba' },
  async ({ paginaAutenticada: page }) => {
    const menu = new MenuNavegacion(page);

    await given('el usuario autenticado accede al sistema', async () => {
      await expect(page).toHaveURL(/.*modulos/);
    });
    await when('navega al módulo Reteica > Archivos > Terceros', async () => {
      await menu.navegar(['Reteica', 'Archivos', 'Terceros']);
    });
    await then('el listado de Terceros carga correctamente con sus controles visibles', async () => {
      await expect(page).toHaveURL(/.*taxtime\/terceros$/);
    });
  }
);
El ID de caso en el nombre del test (TC-TER-01, TC-DEC-001) sigue el formato TC-<MÓDULO>-<número> y corresponde directamente al ID del caso de prueba en Azure DevOps. Esto permite trazar automáticamente fallos del pipeline hasta el Work Item de Azure. El prefijo del módulo se elige al crear la suite: TER para Terceros, DEC para Declaración, CON para Contribuyentes, etc.

​
Bloques serial vs paralelo

Por defecto Playwright ejecuta los tests dentro de un archivo en paralelo (cada test en su propio worker). Sin embargo, las secuencias CRUD que tienen dependencias de estado entre sí — crear un registro, luego editarlo, luego eliminarlo — deben ejecutarse en orden serial en el mismo worker para que el test de edición encuentre el registro creado por el test anterior. Para esto se usa test.describe.configure({ mode: 'serial' }) dentro del bloque describe correspondiente. El patrón real de terceros.spec.js: 
test.describe('Terceros - CRUD', () => {
  test.describe.configure({ mode: 'serial' });
  // TC-TER-04 → TC-TER-05 → TC-TER-06 run in order, sharing state
});
Con esta configuración, si TC-TER-04 (crear) falla, Playwright omite automáticamente TC-TER-05 (editar) y TC-TER-06 (eliminar), evitando errores en cascada por datos faltantes. Los tests de smoke y validaciones no tienen dependencias entre sí y viven en bloques describe separados sin serial, por lo que Playwright los puede paralelizar: 
// ─── BLOQUE 1 — SMOKE (paralelo) ───────────────────
test.describe('Terceros - Smoke', () => {
  // TC-TER-01, TC-TER-02, TC-TER-03 — sin dependencias entre sí
});

// ─── BLOQUE 2 — CRUD SERIAL ─────────────────────────
test.describe('Terceros - CRUD', () => {
  test.describe.configure({ mode: 'serial' });
  // TC-TER-04 → TC-TER-05 → TC-TER-06 — dependencias encadenadas
});

// ─── BLOQUE 3 — VALIDACIONES (paralelo) ─────────────
test.describe('Terceros - Validaciones y Búsqueda', () => {
  // TC-TER-07 ... TC-TER-14 — sin dependencias entre sí
});
Los tests E2E en suites/Reteica/e2e/ son siempre seriales porque cada test del flujo depende del estado dejado por el anterior (p. ej. TC-DEC-002 verifica el recálculo del interés de mora usando la declaración del Periodo 1 creada por TC-DEC-001): 
test.describe('Flujo declaración contribuyente', () => {
  test.describe.configure({ mode: 'serial' });

  test('TC-DEC-001 — Happy Path: Presentar declaración completa (Periodo 1)',
    { tag: '@e2e @contribuyentes @reteica @pasto @corpoboyaca @sysman-predial' },
    async ({ paginaAutenticada: page, establecimientoData }) => { /* ... */ }
  );

  test('TC-DEC-002 — Happy Path: Presentar declaración Periodo 2 (recálculo interés de mora)',
    { tag: '@e2e @contribuyentes @reteica @pasto @corpoboyaca @sysman-predial' },
    async ({ paginaAutenticada: page, establecimientoData }) => { /* ... */ }
  );

  test('TC-DEC-003 — Negativo: Establecimiento ya usado en declaración del mismo Periodo',
    { tag: '@e2e @contribuyentes @reteica @pasto @corpoboyaca @sysman-predial' },
    async ({ paginaAutenticada: page, establecimientoData }) => { /* ... */ }
  );
});

​
Etiquetado de tests

Las etiquetas (tag) son la principal forma de filtrar la ejecución. Cada test tiene un conjunto de tags que combina: nivel (@smoke, @regression, @e2e), módulo (@terceros, @contribuyentes, @reteica) y tipo de caso (@crud, @search, @negative, @boundary). El tag @tagprueba marca los tests que se ejecutan en el pipeline de smoke diario. 
# Ejecutar solo tests de humo
npx playwright test --grep "@smoke"

# Ejecutar solo flujos E2E
npx playwright test --grep "@e2e"

# Ejecutar solo tests de Terceros
npx playwright test --grep "@terceros"

# Ejecutar el pipeline de smoke diario
npm run test:smoke

Guía: Escribir tests

Paso a paso para crear un nuevo spec siguiendo las convenciones del proyecto.

Guía: Ejecutar tests

Comandos disponibles, filtros por tag y ejecución en modo headless o headed.

Build docs developers (and LLMs) love

Get started for freeTalk to us