Playwright controla navegadores y prueba aplicaciones web. En el ecosistema de JavaScript y TypeScript, Playwright Test añade un ejecutor, fixtures, aserciones, proyectos e informes. QA se beneficia de comandos cómodos, aislamiento de estado e información detallada de los fallos.
La herramienta sirve para recorridos de usuario, comprobaciones del estado de la interfaz y algunas tareas de API. La espera automática no sustituye el conocimiento de la aplicación: que un botón pueda accionarse no significa que un proceso de negocio haya terminado, y una respuesta HTTP correcta no significa que sus datos sean correctos.
Instalación y reproducibilidad
Para un proyecto de formación nuevo, utiliza npm init playwright@latest. Elige JavaScript o TypeScript y la instalación de navegadores. Usa una versión de Node compatible con la versión seleccionada. En un repositorio existente, conserva package-lock.json e instala las dependencias con npm ci.
Las versiones de los navegadores están vinculadas a la versión instalada de Playwright. Tras actualizar el paquete, actualiza sus navegadores y comprueba las dependencias del sistema de CI. Un ejecutable global arbitrario puede introducir diferencias entre máquinas locales y agentes, así que documenta explícitamente esa decisión.
Localizadores y nombres accesibles
Playwright admite localizadores por rol, etiqueta, texto e ID de prueba. Un localizador describe cómo encontrar un elemento en el estado actual de la página. Es preferible a guardar una referencia antigua a un nodo DOM que la aplicación puede sustituir al renderizar.
Elige los atributos según su significado. En un formulario, getByLabel vincula la prueba con su etiqueta accesible; para un botón, getByRole con un nombre expresa una acción del usuario. Si coinciden varios elementos, limita el contenedor. Elegir automáticamente la primera coincidencia puede ocultar la ambigüedad y pulsar el botón equivocado.
Un ejemplo independiente
En el proyecto creado, guarda tests/profile.spec.js. El ejemplo usa una página en memoria sin servidor. Ejecuta npx playwright test tests/profile.spec.js. La regla de formación rechaza un nombre vacío y muestra éxito para un nombre no vacío; no se guardan datos realmente.
const { test, expect } = require('@playwright/test');
test('validates the name after submission', async ({ page }) => {
await page.setContent(`
<label>Name <input id="name"></label>
<button id="save">Save</button><p role="status"></p>
<script>
document.querySelector('#save').onclick = () => {
const name = document.querySelector('#name').value.trim();
setTimeout(() => {
document.querySelector('[role=status]').textContent =
name ? 'Saved' : 'Enter a name';
}, 100);
};
</script>`);
await page.getByRole('button', { name: 'Save' }).click();
await expect(page.getByRole('status')).toHaveText('Enter a name');
await page.getByLabel('Name').fill('Anna');
await page.getByRole('button', { name: 'Save' }).click();
await expect(page.getByRole('status')).toHaveText('Saved');
});Espera un error con un valor vacío y, después, éxito con un valor válido. toHaveText repite la observación hasta que se cumple la condición o se agota el tiempo. Las acciones y aserciones asíncronas requieren await: omitirlo puede provocar un orden incorrecto y comprobaciones sin terminar.
Qué espera realmente la herramienta
Antes de una acción, Playwright comprueba las condiciones necesarias, como visibilidad y posibilidad de interacción, según la operación. No sabe si han terminado un cálculo en segundo plano, el envío de un correo o el procesamiento de una cola. Esos resultados requieren una condición observable independiente.
Prefiere aserciones web que reintentan para una UI dinámica. Obtener el texto inmediatamente y compararlo con un assert simple comprueba un único instante. Sin embargo, no sustituyas todas las esperas por tiempos enormes: si el evento no debe ocurrir, esperar más no arregla el escenario.
Pasar a un perfil real
Crea un usuario de prueba independiente, abre su área de cuenta y envía un nombre que solo contenga espacios. Espera un error y el valor original guardado. En otro escenario, envía un nombre válido nuevo y recupera el perfil mediante la UI o la API, según el objetivo de la prueba.
Una prueba que simula la red confirma cómo gestiona el cliente la respuesta proporcionada. Mantén una comprobación de integración independiente sin sustituir esa operación para verificar la persistencia real. Haz visible en el nombre de la suite la diferencia entre un error de UI controlado y una conexión real con el backend.
Fixtures e independencia
Playwright Test utiliza contextos para crear un estado del navegador aislado para cada prueba. Esto ayuda con cookies y almacenamiento, pero no aísla automáticamente los registros del servidor. Dos contextos que usan una cuenta aún pueden modificar el mismo perfil o carrito.
Las fixtures pueden preparar usuarios, clientes de API y entidades necesarias. Elige su alcance deliberadamente. Un recurso compartido a nivel de worker debe ser seguro para todas las pruebas de ese worker; conviene crear por separado los datos modificables de cada escenario.
Proyectos y matriz de navegadores
Los proyectos describen configuraciones como navegador, tamaño de ventana, configuración regional y otros parámetros. Ejecuta una matriz basada en riesgos en lugar de probar automáticamente todas las combinaciones posibles. Confirma primero el recorrido crítico y añade después áreas sensibles al entorno seleccionado.
La emulación móvil no sustituye a un teléfono real con su teclado, permisos e integraciones del sistema. Tampoco debe presentarse WebKit automatizado como una prueba completa del Safari de los usuarios. Registra las limitaciones de cobertura junto con los resultados.
Trazas e investigación
Trace Viewer ayuda a examinar acciones y el estado de la página alrededor de un fallo. Guarda las trazas según una política acordada, por ejemplo, en reintentos o fallos, y hazlas accesibles desde CI. Antes de publicarlas, considera qué datos aparecen en los registros de red y las capturas.
Empieza por la primera expectativa incumplida: qué solicitud se envió, qué respuesta llegó y qué mostró la UI. Evita reescribir a ciegas un localizador cuando el backend no está disponible. Una repetición en verde aporta información, pero el fallo original sigue necesitando clasificación.
Para un escenario con varios usuarios, crea dos contextos independientes e identifica el rol de cada participante en el informe. Guardar un archivo de estado del almacenamiento para acelerar el inicio de sesión no debe mezclar cuentas ni exponer datos de sesión en un artefacto público. Confirma que el estado pertenece al entorno requerido y sigue vigente. Si falla la preparación de la autenticación, identifica esa etapa: decenas de errores posteriores de elementos del área de cuenta no son defectos independientes de la interfaz.
Errores y conclusiones prácticas
Los problemas habituales incluyen omitir await, compartir cuentas modificables, forzar clics sin investigar y comprobar solo un mensaje. Edita las pruebas generadas: los generadores ayudan a empezar, pero no eligen los riesgos, datos ni criterios de éxito del equipo.
Una suite fiable de Playwright combina aislamiento, localizadores claros, resultados de negocio explícitos y artefactos útiles. El inicio rápido de la herramienta aporta valor cuando el equipo gestiona con el mismo cuidado el estado del servidor y los límites de cobertura.
Lecturas adicionales
- →Playwright: instalación
- →Playwright: espera automática
- →Playwright: fixtures de prueba
- →Playwright: visor de trazas
Un ejercicio local reproducible
El proyecto de práctica preparado fija @playwright/test 1.59.1 con un archivo de bloqueo y utiliza una fixture local en Python. Sus siete casos de Chromium prueban el formulario de apodo con entradas vacías, cortas, límite, demasiado largas, con espacios y Unicode. Cada caso obtiene su propia página y declara el resultado esperado. No intervienen cuentas externas ni sitios de producción.
npm ci
npx playwright install chromium
npm test
# If a test fails and produces a trace:
npx playwright show-trace test-results/<case-directory>/trace.zipLa configuración inicia el servidor local y conserva las trazas si hay fallos. Los localizadores usan la etiqueta del campo y el rol del botón para comunicar la intención del usuario. Las aserciones reintentan hasta cumplir la condición o agotar el tiempo; este formulario síncrono no necesita llamadas sleep arbitrarias.
await page.goto("/demo.html");
await page.getByLabel("Nickname").fill("ab");
await page.getByRole("button", { name: "Validate" }).click();
await expect(page.getByRole("alert")).toHaveText("Use 3–12 ASCII letters.");
await expect(page.getByLabel("Nickname")).toBeFocused();Para practicar un fallo deliberado, cambia el texto de error esperado en una prueba local, ejecuta solo esa prueba, inspecciona la traza conservada y restaura la aserción. Una prueba aprobada demuestra que esta fixture cumple estas comprobaciones; no demuestra que un producto real sea accesible ni esté probado exhaustivamente. Añade el flujo real y las aserciones del backend al adaptar el ejemplo.