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.

Los fixtures de Playwright son funciones de setup/teardown que se ejecutan antes y después de cada test (o una sola vez por worker) y se inyectan como argumentos a la función del test. En automation-arqc los fixtures cumplen dos roles: gestionan la autenticación (para que cada test comience ya con la sesión establecida) y precreación de datos (para que los tests E2E dispongan de un tercero, contribuyente y establecimiento reales en la base de datos antes de que el test empiece). Esto desacopla completamente la preparación de datos de la lógica de aserciones del test.

​
Jerarquía de fixtures

Los fixtures de Reteica forman una cadena de dependencias: cada nivel extiende el anterior con un fixture adicional. Playwright garantiza el teardown en orden LIFO (Last In, First Out) — el establecimiento se elimina primero, luego el contribuyente, y finalmente el tercero. 
auth.fixture.js  →  fixtures/index.js (paginaAutenticada)
                        ↓
               tercero.fixture.js (terceroData)
                        ↓
          contribuyente.fixture.js (contribuyenteData)
                        ↓
          establecimiento.fixture.js (establecimientoData)
Cada fixture del eslabón inferior extiende el del eslabón superior con base.extend(...). Un test E2E que necesita el stack completo importa directamente establecimiento.fixture.js y obtiene los cuatro fixtures (paginaAutenticada, terceroData, contribuyenteData, establecimientoData) en un solo import.

​
paginaAutenticada

paginaAutenticada es el fixture base definido en fixtures/auth.fixture.js y re-exportado por fixtures/index.js. Lee la sesión guardada en playwright/.auth/user.json, la inyecta en el sessionStorage del navegador antes de que Angular arranque, navega a BASE_URL y espera a que la URL contenga /modulos y el mat-drawer-inner-container sea visible. El resultado es una instancia de page ya autenticada lista para usar en el test. 
import { test as base, expect } from '@playwright/test';
import { readFileSync } from 'fs';
import { resolve } from 'path';
import dotenv from 'dotenv';

dotenv.config({ path: resolve(__dirname, '../.env') });

const authFile = resolve(__dirname, '../playwright/.auth/user.json');

const test = base.extend({
  paginaAutenticada: async ({ page }, use) => {
    const authData = JSON.parse(readFileSync(authFile, 'utf8'));

    await page.addInitScript((sessionData) => {
      for (const [key, value] of Object.entries(sessionData)) {
        window.sessionStorage.setItem(key, value);
      }
    }, authData.sessionStorage);

    await page.goto(process.env.BASE_URL, { timeout: 60000, waitUntil: 'domcontentloaded' });
    await page.waitForURL('**/modulos**', { timeout: 30000 });
    await page.locator('.mat-drawer-inner-container').waitFor({ state: 'visible', timeout: 30000 });

    await use(page);
  }
});

export { test, expect };

​
Uso en un test de componente

Cualquier spec que solo necesite la sesión importa desde fixtures/index.js (que re-exporta auth.fixture.js): 
import { test, expect } from '../../fixtures/index.js';

test('my test', async ({ paginaAutenticada: page }) => {
  await expect(page).toHaveURL(/.*modulos/);
});
El alias paginaAutenticada: page en la desestructuración hace que dentro del cuerpo del test la variable se llame page, igual que en un test estándar de Playwright, evitando cambiar la interfaz mental.

​
Fixtures de datos Reteica

Los fixtures terceroData, contribuyenteData y establecimientoData son todos de scope worker: se ejecutan una sola vez por proceso worker de Playwright (no una vez por test). Esto es eficiente cuando una suite serial de tres tests (crear → editar → eliminar) necesita el mismo conjunto de datos preexistentes — el fixture los crea una vez, los tres tests los usan, y el teardown los elimina al final. Cada fixture sigue el mismo patrón:
1

Generar seed único

Usa Date.now().toString().slice(-9) para obtener un número de 9 dígitos único por ejecución. Este valor se usa como NIT del tercero, parte del nombre del contribuyente y del establecimiento.
2

Setup: crear datos con un browser auxiliar

Abre un contexto nuevo (independiente del contexto del test), inyecta la sesión, navega al módulo correspondiente y realiza la creación a través de los page objects.
3

Entregar datos al test con `use()`

Llama a await use({ seed, nit, razonSocial, ... }) para que el test reciba el objeto con los datos creados.
4

Teardown: eliminar datos (automático)

Después de que use() retorna, el fixture ejecuta la función de eliminación correspondiente. Si falla (p. ej. el test ya eliminó el registro), el error se suprime con .catch(() => {}) para no contaminar el resultado del test.

​
Referencia de fixtures de datos

FixtureArchivoDatos entregados al testDepende de
terceroDatatercero.fixture.js{ seed, nit, razonSocial }paginaAutenticada
contribuyenteDatacontribuyente.fixture.js{ seed, nit, razonSocial, matricula }terceroData
establecimientoDataestablecimiento.fixture.js{ seed, nit, razonSocial, matricula, nombreEstablecimiento }contribuyenteData

​
Ejemplo: test E2E con establecimientoData

Un test E2E que necesita el stack completo solo importa establecimiento.fixture.js. El fixture ya garantiza que tercero, contribuyente y establecimiento existen en la base de datos antes de que el cuerpo del test comience a ejecutarse. 
import { test } from '../../../fixtures/reteica/establecimiento.fixture.js';

test('TC-DEC-001 — Presentar declaración',
  { tag: '@e2e @contribuyentes @reteica' },
  async ({ paginaAutenticada: page, establecimientoData }) => {
    const { seed, razonSocial, nombreEstablecimiento } = establecimientoData;
    // El fixture ya creó tercero + contribuyente + establecimiento
    // El teardown los eliminará automáticamente al finalizar
  }
);

​
Orden de teardown (LIFO)

Dado que establecimientoData depende de contribuyenteData que depende de terceroData, Playwright deshace la cadena en orden inverso: 
Teardown orden:
  1. establecimientoData  →  eliminarEstablecimientoConBrowser()
  2. contribuyenteData    →  eliminarContribuyenteConBrowser()
  3. terceroData          →  eliminarTerceroConBrowser()
Esto es importante porque el sistema no permite eliminar un tercero que tenga un contribuyente asociado, ni un contribuyente que tenga establecimientos — el orden inverso respeta esas restricciones de integridad referencial.
El archivo playwright/.auth/user.json debe existir antes de ejecutar cualquier test que use estos fixtures. Si no existe, el fixture lanzará un error al intentar leer las credenciales de sesión. Genera la sesión ejecutando el setup global antes de tu primera ejecución:
node playwright/global-setup.js
En local, el archivo se reutiliza si tiene menos de 8 horas de antigüedad. En CI, el pipeline lo genera siempre desde cero en la etapa “Ejecución de Pruebas”.

Referencia: Auth Fixture

API detallada de paginaAutenticada: parámetros, comportamiento y opciones de configuración.

Referencia: Fixtures de Reteica

API completa de terceroData, contribuyenteData y establecimientoData con todos los campos expuestos.

Build docs developers (and LLMs) love

Get started for freeTalk to us