Mejora de la Resistencia y Reutilización en Pruebas E2E con Playwright y Zod

En el proyecto TuTiendaWeb, nos enfocamos en mejorar la estabilidad y eficiencia de nuestras pruebas de extremo a extremo (E2E) con Playwright. Recientemente, abordamos varios desafíos identificados en una revisión de código, buscando hacer nuestras pruebas más robustas, fáciles de mantener y menos propensas a fallos por cambios menores en la interfaz de usuario.

El Problema: Pruebas E2E Frágiles y Repetitivas

Nuestras pruebas E2E, aunque esenciales para garantizar la calidad del producto, mostraban puntos débiles significativos. Los selectores basados en la posición de elementos (.nth(1)) o en texto (placeholder('0.00').first()) eran intrínsecamente frágiles, fallando ante pequeños ajustes visuales o de estructura del DOM. Además, la lógica de autenticación del usuario propietario se duplicaba entre diferentes suites de pruebas, y los contratos de datos para la importación de productos estaban definidos en múltiples lugares, creando inconsistencias y dificultando el mantenimiento.

La Solución: Estrategias para la Robustez y la Reutilización

Implementamos varias mejoras clave que transformaron la fiabilidad y eficiencia de nuestras pruebas.

1. Robustez de los Selectores con data-testid

Para combatir la fragilidad de los selectores, migramos a un enfoque basado en atributos data-testid. Estos atributos proporcionan un punto de anclaje estable en el DOM, desacoplando los selectores de la estructura interna del componente o del texto visible, que pueden cambiar con frecuencia.

// Antes (frágil)
await page.locator('input[placeholder="0.00"]').first().fill('12.34');
await page.locator('button:nth-child(2)').click();

// Después (robusto con data-testid)
await page.getByTestId('product-price-input').fill('12.34');
await page.getByTestId('save-product-button').click();

Este cambio, aunque aparentemente pequeño, tiene un impacto significativo en la estabilidad de las pruebas. Ahora, si se añade un nuevo campo o cambia el orden de los botones, nuestras pruebas seguirán funcionando, siempre que el data-testid se mantenga. Esto minimiza la necesidad de actualizaciones constantes de las pruebas por cambios no funcionales en la UI.

2. Centralizando Contratos de Datos con Zod

Una de las mayores mejoras en la reutilización provino de usar Zod como fuente única de verdad para la definición de columnas de importación de productos. Antes, esta definición se triplicaba en el diálogo de importación de la UI y en la generación de fixtures E2E para pruebas. Al derivar la lista de columnas directamente de un esquema Zod, garantizamos que el frontend y los datos de prueba usen exactamente el mismo contrato.

import { z } from 'zod';

// Define el esquema de la fila de importación de productos
const productImportRowSchema = z.object({
  sku: z.string(),
  name: z.string(),
  price: z.number(),
  stock: z.number().optional(),
});

// Derivar las columnas directamente del esquema
const IMPORT_COLUMNS = Object.keys(productImportRowSchema.shape);
// Esto produciría: ['sku', 'name', 'price', 'stock']

Este enfoque no solo reduce la repetición de código y la

Generated with Gitvlg.com