Resultados de Playwright en tu herramienta de gestión de pruebas

Puedes enviar los resultados de Playwright a una herramienta de gestión de pruebas de dos formas: hacer que Playwright escriba un archivo JUnit XML e importarlo en un paso posterior de CI, o registrar en playwright.config un reporter que envíe los resultados mientras corren las pruebas. JUnit XML funciona con casi cualquier herramienta, pero no lleva pasos y suele quedarse con un resultado por prueba. Un reporter dedicado conserva cada intento de un reintento, el árbol anidado de test.step y las capturas, los videos y los traces que generó Playwright.

¿Cuáles son las dos formas de enviar resultados de Playwright?

Toda integración entre Playwright y una herramienta de gestión de pruebas es o bien un archivo que subes después de la ejecución, o bien un reporter que corre dentro de ella. La diferencia decide qué llega a la herramienta y cuánta configuración te toca mantener.

Las filas de pasos y reintentos siguen cómo registra Probara cada camino (documentación de Probara: integraciones CI); revisa la documentación de importación de tu propia herramienta para esas dos filas. Playwright te deja usar varios reporters a la vez, así que cualquiera de las dos opciones conserva la salida de la terminal y el informe HTML (Playwright: Reporters).

Opción 1: exportar JUnit XML e importarlo después de las pruebas

JUnit XML es el camino portable: Playwright escribe el archivo y un paso aparte de CI lo sube. El reporter junit incluido en Playwright escribe el archivo que indiques en su opción outputFile, o el nombre de la variable de entorno PLAYWRIGHT_JUNIT_OUTPUT_NAME (Playwright: Reporters):

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [['list'], ['junit', { outputFile: 'reports/junit.xml' }]],
});

Luego el paso de importación envía ese archivo a tu herramienta, y tiene que correr aunque fallen las pruebas. Una prueba fallida hace fallar el paso de pruebas, así que en GitHub Actions el paso de importación necesita if: always(); sin él, justo el build en rojo es el que nunca se reporta (documentación de Probara: CLI).

- name: Report to Probara
  if: always()
  run: npx @probara/cli import junit reports/junit.xml
  env:
    PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }}
    PROBARA_PROJECT: SHOP

Lo que pierdes es estructura. JUnit XML tiene una suite, un caso de prueba y un mensaje de fallo; no tiene pasos (documentación de Probara: integraciones CI). La importación de JUnit XML de Playwright en BrowserStack Test Management, por ejemplo, recibe el archivo, un nombre de proyecto y un nombre de ejecución, y su informe de ejemplo solo contiene suites, casos de prueba y fallos (documentación de BrowserStack). Algunas opciones de JUnit también cambian el archivo: includeProjectInTestName antepone el proyecto de Playwright al nombre de cada prueba, lo que cambia cómo ve la prueba una herramienta que empareja por nombre.

Opción 2: registrar un reporter que envía los resultados durante la ejecución

Un reporter dedicado es un paquete que añades al array reporter de playwright.config; recibe la ejecución a través de la API de reporters de Playwright y la envía a la herramienta. Esa API expone mucho más que JUnit XML: cada TestStep tiene un título, una duración en milisegundos, el error que lanzó y sus pasos hijos (Playwright: TestStep).

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [['list'], ['@probara/playwright-reporter', { projectId: 'SHOP' }]],
});

Así, el resultado en la herramienta puede mostrar dónde falló una prueba, no solo que falló: el paso anidado que agotó el tiempo, su error y la captura tomada en él.

Lo que cedes es dependencia y versiones. Un reporter está escrito para una sola herramienta, así que cambiar de herramienta implica cambiar de paquete, y tiene sus propias versiones mínimas de Node.js y de @playwright/test. Fíjalo en package.json para que una actualización nunca cambie un pipeline por sorpresa.

¿Cómo encuentra cada prueba de Playwright su caso de prueba?

Una prueba llega al caso correcto porque nombra el caso o porque la herramienta la reconoce por una clave construida a partir de la propia prueba. Elige una regla para toda la suite antes de la primera subida, porque decide si el historial se acumula en un caso o se reparte entre duplicados.

• Nombra el caso. Pon el id del caso en la prueba, como anotación o en el título. Las anotaciones de Playwright tienen un type y una description y están disponibles en la API de reporters, así que funcionan con cualquier reporter (Playwright: Annotations):

  test('pays with a card', {
    annotation: { type: 'probara_case', description: 'SHOP-12' },
  }, async ({ page }) => {
    // ...
  });

• Deja que una clave lo encuentre. Las herramientas que emparejan por clave la construyen con el archivo y la ruta de títulos, por ejemplo checkout.spec.ts > checkout > pays with a card (documentación de Probara: vincular pruebas a casos).

Usa ids cuando los casos ya existen, escritos a mano o importados. Usa claves cuando las pruebas automatizadas son la fuente de verdad y quieres que la herramienta cree un caso por cada prueba nueva. Con claves, renombrar una prueba, un bloque describe o un archivo crea un caso nuevo, porque la clave cambia; con un id, renombrar no cuesta nada.

¿Cómo cambian los reintentos y el sharding lo que se reporta?

Los reintentos y el sharding son los dos ajustes que más a menudo hacen que una herramienta de gestión de pruebas no coincida con Playwright. Necesitan una decisión, no un valor por defecto.

Reintentos. Playwright no reintenta por defecto. Con retries configurado, marca una prueba como flaky cuando falló en la primera ejecución y pasó en un reintento, y como failed cuando falló en todos los intentos (Playwright: Retries). Si la herramienta solo recibe el resultado final, una prueba inestable parece un pase limpio y la evidencia desaparece. Envía cada intento cuando puedas; nuestra guía sobre cómo encontrar pruebas inestables muestra qué hacer con ese historial.

Sharding. npx playwright test --shard=1/4 ejecuta una cuarta parte de la suite en cada máquina, y por defecto cada shard se reportaría como una ejecución distinta. La respuesta de Playwright es el reporter blob: cada shard escribe un informe blob, y npx playwright merge-reports los combina después en un solo informe (Playwright: Sharding). Puedes fusionarlos directamente con el reporter de tu herramienta:

npx playwright merge-reports --reporter @probara/playwright-reporter ./all-blob-reports

La alternativa es crear primero una ejecución y que cada shard reporte en ella. Así ves resultados mientras los shards siguen corriendo, pero necesitas un job final que cierre la ejecución aunque fallen shards.

¿Cuál deberías elegir?

Elige según lo que necesitas ver cuando falla una prueba, no según qué configuración es más corta.

1. Usa JUnit XML cuando trabajas con varios frameworks (pytest, Maven Surefire, Jest) y quieres un solo paso de importación para todos, o cuando tu herramienta no tiene reporter de Playwright.

2. Usa un reporter dedicado cuando Playwright es tu framework principal y quienes revisan los fallos necesitan el paso que se rompió, el trace y cada reintento.

3. Pasa de JUnit a un reporter sin perder historial solo si el reporter construye las mismas claves de caso que la importación de JUnit. Compruébalo con una ejecución de prueba (dry run) antes del cambio; si no, cada prueba se convierte en un caso nuevo.

4. Conserva el informe HTML de Playwright en cualquier caso. Una herramienta de gestión de pruebas guarda el historial entre ejecuciones; el informe HTML sigue siendo la forma más rápida de abrir un trace.

Dónde encaja Probara

Probara admite los dos caminos. La CLI de Probara importa JUnit XML de cualquier framework con npx @probara/cli import junit reports/junit.xml, y @probara/playwright-reporter envía cada intento como un resultado propio, con pasos anidados, capturas, videos y traces. Los dos crean una ejecución automatizada con el nombre del build de CI, vinculan las pruebas por id de caso o clave de automatización, crean los casos que aún no existen y cierran la ejecución. El reporter construye las mismas claves que una importación de JUnit del informe de Playwright, así que un proyecto puede pasar de uno al otro y conservar todos sus casos (migrar). Para pipelines con sharding, la guía de sharding cubre tanto la fusión de informes blob como compartir una sola ejecución. Enviar resultados desde CI requiere un plan Pro o Enterprise, o una prueba de Pro.

Preguntas frecuentes

¿Puedo usar el reporter HTML y un reporter de gestión de pruebas a la vez?

Sí. La opción reporter de Playwright acepta un array, y cada reporter de la lista recibe la misma ejecución, así que puedes mantener list, html y un reporter de gestión de pruebas juntos.

¿El JUnit XML de Playwright incluye los reintentos?

Con la opción onlyFailures, Playwright conserva cada intento de las pruebas que incluye, también las inestables, pero el archivo queda limitado a resultados inesperados, pruebas inestables e interrumpidas (Playwright: Reporters). Cuando Probara importa JUnit XML, registra un resultado por prueba y resume los intentos anteriores en las notas cuando el informe los conserva.

¿Un npx playwright test local envía resultados a la herramienta?

Depende del reporter, así que revisa su documentación. El reporter de Probara lee el token del entorno y se queda desactivado cuando no hay token ni proyecto, así que las ejecuciones locales, y los pull requests desde forks que no reciben secretos, no envían nada.

¿Qué pasa con los resultados cuando renombro una prueba?

Si la prueba está vinculada por id de caso, el resultado sigue llegando al mismo caso. Si se empareja por clave de automatización, el nombre nuevo genera una clave nueva y la herramienta crea un caso nuevo, así que añade el id del caso antes de renombrar.