Las buenas prácticas oficiales de Playwright, explicadas en español
La documentación oficial de Playwright incluye una página de best practices que todo automatizador debería conocer — pero está en inglés y es fácil pasarla por alto. Aquí está completa, en español y con nuestros comentarios de campo.
Filosofía de testing (lo primero que dice la guía oficial)
Prueba el comportamiento visible del usuario
"Los tests automatizados deben verificar que el código funciona para el usuario final" — evitando detalles de implementación internos.
Es la regla madre: si el usuario no lo ve ni lo experimenta, tu e2e no debería assertarlo. Nombres de clases CSS, estructura del DOM, estado interno de componentes — nada de eso es comportamiento.
Aísla los tests por completo
Cada test corre con su propio contexto: storage, cookies y datos independientes. El setup repetido va en hooks beforeEach (o mejor aún, fixtures) — nunca heredado del test anterior.
No pruebes dependencias de terceros
Sitios externos y servidores que no controlas no se testean: se simulan con la API de red de Playwright. Tu suite no debe ponerse roja porque el proveedor de mapas está lento.
Bases de datos controladas
Si pruebas contra datos, que sea un entorno cuyo estado controlas y conoces — condiciones consistentes en cada corrida.
Prácticas técnicas oficiales
Locators, siempre — y de los accesibles
La guía es explícita: priorizar getByRole() y getByLabel() sobre CSS/XPath, que "se rompen fácilmente". Y encadenar/filtrar para precisión:
const producto = page.getByRole('listitem').filter({ hasText: 'Corte' });
await producto.getByRole('button', { name: 'Reservar' }).click();
Web-first assertions
// ✅ Oficial: espera y reintenta hasta que se cumpla
await expect(page.getByText('Bienvenida')).toBeVisible();
// ❌ Anti-patrón documentado: evalúa una sola vez
expect(await page.getByText('Bienvenida').isVisible()).toBe(true);
Debugging: local con VS Code, CI con Trace Viewer
La guía recomienda la extensión oficial de VS Code para depurar localmente, y en CI traces en vez de videos: el Trace Viewer da timeline, snapshots del DOM, red y consola — un video solo muestra píxeles.
Soft assertions para verificaciones múltiples
await expect.soft(page.getByTestId('status')).toHaveText('Exitoso');
// el test continúa aunque falle, y reporta todo al final
Útiles para auditar varias cosas de una página sin frenar en la primera — con moderación: el fallo duro sigue siendo la norma.
Operación (también es parte de la guía oficial)
- Multi-navegador por configuración: proyectos Chromium/Firefox/WebKit en el config, no suites duplicadas.
- Paralelismo y sharding: tests en paralelo por defecto;
--shard=1/3para repartir entre máquinas. - CI en Linux (más barato) y ejecutar los tests con frecuencia.
- Dependencias al día:
npm i -D @playwright/test@latestpara recibir los navegadores más recientes. - Linting: TypeScript + ESLint con
no-floating-promises— el olvido deawaites el bug #1 de suites Playwright, y esta regla lo vuelve imposible.
Nuestro veredicto
Es de las mejores páginas de buenas prácticas del ecosistema: corta, opinionada y correcta. Si comparas con nuestra guía de campo de Playwright, verás que coinciden en el fondo — la oficial define el estándar, la nuestra agrega el "cómo se ve cuando se ignora". Léelas juntas, y practica ambas en el curso gratuito de Playwright pro.
Fuente: playwright.dev/docs/best-practices (Microsoft, documentación oficial).