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.

Para añadir un nuevo test a automation-arqc necesitas conocer tres cosas: cómo importar el fixture de autenticación correcto, qué Page Objects comunes están disponibles para navegar y operar la UI, y cómo expresar los pasos con la sintaxis BDD de gherkin-lite. Esta guía cubre cada punto con ejemplos reales tomados de la suite.

​
Anatomía de un spec

Todo spec de automation-arqc sigue la misma estructura de imports, describe anidado y bloques given / when / then. El ejemplo siguiente muestra el esqueleto mínimo para un test de navegación y carga de listado:
guides/example.spec.js
import { expect } from '@playwright/test';
const { given, when, then } = require('gherkin-lite');
import { test } from '../../fixtures/index.js';
import { MenuNavegacion } from '../../pages/common/menu-navegacion';
import { AccionesCrud } from '../../pages/common/acciones-crud';
import { ComponentesTabla } from '../../pages/common/componentes-tabla';

const MENU_PATH = ['Reteica', 'Archivos', 'Terceros'];

test.describe('MiModulo - Smoke', () => {
  test(
    'TC-XXX-01 — Carga del listado',
    { tag: '@smoke @mimodulo @reteica @tagprueba' },
    async ({ paginaAutenticada: page }) => {
      const menu = new MenuNavegacion(page);
      const crud = new AccionesCrud(page);
      const tabla = new ComponentesTabla(page);

      await given('el usuario autenticado está en el sistema', async () => {
        await expect(page).toHaveURL(/.*modulos/);
      });

      await when('navega al módulo', async () => {
        await menu.navegar(MENU_PATH);
      });

      await then('el listado carga', async () => {
        await expect(tabla.btnFiltrar).toBeVisible();
      });
    }
  );
});
Los tres Page Objects comunes que aparecen en casi todos los specs son:
  • MenuNavegacion — despliega el acordeón de Angular Material y hace clic en la entrada indicada por la ruta.
  • AccionesCrud — abstrae los botones de acción (Agregar, Editar, Guardar, Eliminar, Aceptar).
  • ComponentesTabla — envuelve los controles de la tabla (filtrar, refrescar, paginar, seleccionar fila).

​
Usar datos de prueba con fixtures

Cuando el test necesita que ya exista un registro antes de correr (por ejemplo, para editar o eliminar), en lugar de crear el dato dentro del propio test debes importar el fixture de datos correspondiente. Esto mantiene la lógica de preparación separada de la lógica del test: 
// Sustituye el import de fixtures/index.js por el fixture específico del módulo
import { test } from '../../fixtures/reteica/tercero.fixture.js';

test.describe('MiModulo - Con dato precreado', () => {
  test(
    'TC-XXX-02 — Editar tercero existente',
    { tag: '@crud @mimodulo @reteica' },
    async ({ paginaAutenticada: page, terceroData }) => {
      // terceroData expone: { seed, nit, razonSocial }
      // El registro ya existe en la aplicación antes de que empiece el test.
      // El fixture también se encarga de eliminarlo al terminar (scope: 'worker').
      console.log(`Trabajando con NIT: ${terceroData.nit}`);
    }
  );
});
Del mismo modo, fixtures/reteica/establecimiento.fixture.js expone establecimientoData para tests del subformulario de Establecimientos. Ambos fixtures tienen scope: 'worker', lo que significa que el registro se crea una sola vez para todos los tests del bloque serial y se elimina al final.

​
Bloques serial para CRUD

Cuando varios tests son dependientes entre sí (crear → editar → eliminar), deben ejecutarse en orden y en el mismo worker. Para eso se usa test.describe.configure({ mode: 'serial' }) al inicio del describe que los agrupa: 
test.describe('Terceros - CRUD', () => {
  test.describe.configure({ mode: 'serial' });

  test('TC-TER-04 — Crear un tercero tipo Persona Jurídica', /* ... */);
  test('TC-TER-05 — Editar un tercero', /* ... */);
  test('TC-TER-06 — Eliminar un tercero recién creado', /* ... */);
});
En modo serial, si el primer test falla los siguientes se marcan automáticamente como skipped, evitando errores en cascada difíciles de diagnosticar. Los tests de validación independientes deben ir en un describe separado, sin serial, para aprovechar el paralelismo.

​
Convenciones obligatorias

Cada test debe incluir al menos uno de los tags de tipo que describe su naturaleza:
  • @smoke — test de humo que verifica la carga básica de una pantalla o flujo crítico.
  • @crud — test que cubre operaciones de creación, edición o eliminación de registros.
  • @search — test de filtrado y búsqueda en listados.
  • @negative — test de validación de errores, campos obligatorios o restricciones de negocio.
  • @regression — test de regresión que forma parte de la ejecución completa.
  • @e2e — flujo que recorre varias pantallas para completar un proceso real de usuario (suites/<Modulo>/e2e/flujo-<proceso>.spec.js).
Adicionalmente, los tests que deben incluirse en la suite de humo rápida deben llevar @tagprueba para que npm run test:smoke los incluya.
El nombre de cada test debe comenzar con un identificador único con el formato TC-<MÓDULO>-<número>, por ejemplo:
  • TC-TER-01 — Navegación y carga del listado
  • TC-CON-03 — Filtrar por razón social
El prefijo de módulo es una abreviatura de tres a cinco letras del módulo probado (TER para Terceros, CON para Conceptos, CONT para Contribuyentes, etc.). El número es secuencial dentro del módulo.
Los describes siguen el patrón NombreModulo - TipoBloque, donde el tipo de bloque es uno de: Smoke, CRUD, Validaciones y Búsqueda, o E2E. Por ejemplo:
test.describe('Terceros - Smoke', () => { /* ... */ });
test.describe('Terceros - CRUD', () => { /* ... */ });
test.describe('Terceros - Validaciones y Búsqueda', () => { /* ... */ });
Esto genera una jerarquía legible tanto en la consola como en el reporte Allure.
Siempre que un test crea datos (NIT, nombre, dirección), debe usar una semilla derivada del timestamp para garantizar unicidad entre ejecuciones y evitar colisiones en el servidor de pruebas:
// Al inicio del archivo, fuera de cualquier describe
const nitUnico = Date.now().toString().slice(-9);

const datosBasicos = {
  nit: nitUnico,
  razonSocial: `AUTOTEST QA SAS ${nitUnico}`,
  // ...
};
La semilla se define una sola vez por archivo y se comparte entre todos los bloques que la necesiten (crear, editar, eliminar el mismo registro).
No uses test.only en código que vayas a hacer commit. En CI, la opción forbidOnly: !!process.env.CI de playwright.config.js hace que la suite falle inmediatamente si encuentra un test.only o un describe.only en cualquier archivo. Usa --grep o ejecuta el archivo directamente para focalizar la ejecución durante el desarrollo local.

Build docs developers (and LLMs) love

Get started for freeTalk to us