Playwright Tracing para depurar tests fallidos

Cuando un test automatizado falla, no siempre es obvio qué pasó. Playwright Tracing te permite reconstruir paso a paso lo que ocurrió antes, durante y después de cada acción de tu test, con capturas, DOM renderizado, llamadas de red y logs. Es la herramienta ideal si quieres entender errores en pruebas end to end con Playwright.

¿Cómo activar el tracing en Playwright desde la terminal?

Por defecto, el tracing viene desactivado. Para generarlo necesitas pasar un flag explícito al ejecutar tu test.

En el archivo tienda-online.spec.ts, que ya teníamos de clases anteriores, basta con correr el comando con el parámetro --trace on [02:08]:

bash npx playwright test tienda-online --trace on

Al terminar la ejecución, Playwright genera un archivo .zip con los rastros del test. Para explorarlo abres el reporte como siempre:

bash npx playwright show-report

Dentro del reporte verás un pequeño icono con tres barras que indica que el trace está disponible. Al hacer clic, se abre la vista interactiva del rastro.

¿Qué es el tracing en Playwright? Es un registro detallado de todo lo que hace tu test: capturas, acciones, DOM, red y consola. Funciona como una caja negra que puedes abrir cuando un test falla.

¿Qué información muestra la vista del trace?

La vista del trace se divide en una línea de tiempo superior, un panel central con el estado del navegador y menús laterales con acciones y metadata.

En la línea de tiempo superior aparecen screenshots secuenciales [03:30]. Si pasas el mouse sobre ellos, ves cómo evolucionó la pantalla: el navegador en blanco al inicio, la tienda online cargando, el clic sobre un producto y el mensaje de "Tu compra ha sido exitosa" que estuvo visible apenas milésimas de segundo antes de cerrarse.

En el menú izquierdo aparecen las acciones que ejecutó tu test en orden:

• Crear una nueva página.
• Navegar a la URL indicada.
• Hacer hover sobre un elemento.
• Hacer clic, marcado con un punto rojo sobre el elemento exacto.

¿Por qué el panel central no es solo una captura de pantalla?

Esta es la parte que más sorprende. El panel central muestra un DOM renderizado, no una imagen estática [05:00]. Eso significa que puedes inspeccionar elementos como si fuera una minivista del navegador.

Puedes ver que un elemento es una etiqueta de imagen dentro de un link, que a su vez está dentro de un contenedor, dentro de otro contenedor que forma parte de una lista. Si tu test falla por un elemento que no se pintó bien, aquí lo identificas con precisión.

¿Cómo interpretar el before y after de cada acción?

Cada acción tiene dos estados visuales: lo que pasó antes y lo que pasó después.

Por ejemplo, antes del clic en el botón con signo más, la tienda mostraba sus productos. Después de la acción, la pantalla quedó en blanco [06:20]. Eso indica que la aplicación tardó en responder tras el clic, y es justo ahí donde puedes detectar cuellos de botella o renderizados lentos.

El menú derecho complementa esto con varias pestañas clave:

• Call: muestra la llamada ejecutada, su duración y tiempo de espera.
• Log: detalla cómo Playwright resolvió la acción internamente, esperando que el elemento sea visible, estable y habilitado antes de hacer autoscroll y clic.
• Console: registra mensajes y errores del navegador en ese instante.
• Network: lista las llamadas HTTP, como los GET de archivos CSS que se cargaron al hacer clic.
• Source: señala la línea exacta de tu archivo de test que disparó la acción, por ejemplo await page.locator(...).click().

¿Para qué sirve la pestaña Network del trace? Te permite ver qué recursos se estaban descargando cuando ocurrió la acción. Si un test falla por un archivo que no cargó, aquí lo confirmas.

¿Qué metadata adicional ofrece el trace?

Además de las acciones, el trace guarda contexto técnico que ayuda a reproducir el escenario exacto:

• Archivo de prueba que se ejecutó.
• Tipo de navegador usado (Chromium, Firefox, WebKit).
• Si fue ejecución móvil o de escritorio.
• Tamaño del viewport.

Con todos esos datos, depurar un fallo deja de ser adivinanza y se vuelve un análisis forense.

¿Por qué importa dominar el tracing si vas a leer tests ajenos?

Aquí va una idea que vale la pena subrayar: vas a pasar mucho más tiempo leyendo y entendiendo tests de otras personas que escribiendo los tuyos [09:40]. El tracing es la herramienta que te permite entrar a un test que no conoces, ver qué hace paso a paso y diagnosticar por qué falla sin tener que reconstruir todo el flujo mentalmente.

Existe también una forma alterna de acceder al tracing directamente desde la terminal, sin pasar por el reporte HTML. Revísala en la documentación oficial y déjame ese comando en los comentarios. ¿Cuál encontraste?