# Enviar resultados desde CI con Playwright

> Crea el token de aplicación con el que se autentica el reporter de Probara para Playwright, añádelo a tu configuración de Playwright y consulta qué envía.

La aplicación **Playwright** envía a Probara los resultados de tus pruebas de Playwright desde
cualquier pipeline de CI, con el reporter de Probara para Playwright. Cada ejecución de Playwright se
convierte en una ejecución automatizada con sus resultados, los casos de prueba que nombra y sus
adjuntos.

El reporter se autentica con un **token de aplicación**: un token que pertenece a la organización,
no a una persona. No ocupa ningún puesto y sigue funcionando cuando la persona que lo creó se va.
Esta guía cubre la tarjeta en Probara y la configuración; la
[documentación del reporter](https://docs.probara.net/es/developers/ci-integrations/playwright/) cubre cada
[opción del reporter](https://docs.probara.net/es/developers/ci-integrations/playwright/configuration/), los helpers de prueba y
las [ejecuciones con shards](https://docs.probara.net/es/developers/ci-integrations/playwright/sharding/).

## Antes de empezar

| Necesitas                                                    | Por qué                                                                                                                                                |
| ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Un plan de pago (**Pro** o **Enterprise**, o una prueba Pro) | El envío de resultados desde CI no forma parte del plan Free. En Free, su diálogo muestra **Ver planes** en lugar de **Crear un token de aplicación**. |
| Un **propietario** o **administrador** de Probara            | Solo los propietarios y administradores pueden crear y gestionar tokens de aplicación. Los demás miembros ven la tarjeta sin sus tokens.               |
| Un proyecto de Playwright que se ejecuta en CI               | El reporter se ejecuta con tus pruebas, en el mismo comando `npx playwright test`.                                                                     |

## Configurarla

1. En **Workspace › Integraciones**, selecciona la tarjeta **Playwright**. El diálogo muestra qué
   puede hacer la aplicación y enlaza a esta guía.
2. Abre la pestaña **Tokens de acceso** y selecciona **Crear un token de aplicación**.
3. Escribe un **Nombre del token** y selecciona **Crear token**. Ponle el nombre de lo que lo usa —
   el repositorio o el pipeline — para saber después cuál revocar.
4. Selecciona **Copiar token** en **Copia tu nuevo token**. Es la única vez que Probara lo muestra:
   guárdalo en tu CI como un secreto llamado `PROBARA_API_TOKEN` antes de seleccionar **Listo**.
5. Instala el reporter en tu proyecto de Playwright:

   ```bash
   npm install -D @probara/playwright-reporter
   ```

6. Añádelo a los reporters de `playwright.config`, junto al que lees en la terminal, y sustituye
   `<PROJECT_CODE>` por el ID del Proyecto, por ejemplo `SHOP`:

   ```ts
   // playwright.config.ts
   reporter: [
     ['list'],
     ['@probara/playwright-reporter', { projectId: '<PROJECT_CODE>' }],
   ],
   ```

7. Pasa el secreto a tus pruebas como la variable de entorno `PROBARA_API_TOKEN` y ejecútalas. Por
   ejemplo, en GitHub Actions:

   ```yaml
   - name: Run Playwright tests
     run: npx playwright test
     env:
       PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }}
   ```

El token nunca va en `playwright.config`: el reporter lo lee del entorno. La tarjeta de la página de
Integraciones muestra cuántos tokens activos tiene la aplicación.

## Qué envía el reporter

| Qué                        | Cómo lo registra Probara                                                                                                                                                                                                                                      |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Resultados                 | Un resultado por intento: una prueba reintentada envía cada intento, en orden, y el caso de la ejecución conserva el último resultado. Cada intento queda en el historial del caso.                                                                           |
| Pasos                      | Los pasos que ejecutó cada intento (`test.step`), como un árbol con su estado, su duración y su error, debajo del resultado.                                                                                                                                  |
| Adjuntos                   | Las capturas, los vídeos, las trazas y los demás archivos de un intento, en su resultado — o en el paso en el que se adjuntaron. Una traza se abre en el visor de trazas directamente desde el resultado.                                                     |
| Parámetros                 | Los parámetros con los que se ejecutó un intento. Un nombre que el caso declara selecciona su caso de ejecución; cualquier otro, como el `project` de Playwright, se muestra solo con el resultado, como contexto.                                            |
| Casos de prueba nuevos     | Una prueba sin caso crea uno, en una ruta de suites construida a partir de su archivo y sus bloques `describe`.                                                                                                                                               |
| Casos de prueba existentes | Un caso archivado al que la prueba reporta se restaura. Un caso encontrado por su clave de automatización se mueve a la suite en la que está ahora la prueba; un caso vinculado por su ID conserva su suite. Su título, sus pasos y sus campos nunca cambian. |
| Campos de un caso nuevo    | Su descripción, sus etiquetas, sus pasos y sus campos — campos de sistema como la prioridad o la severidad, y custom fields por nombre. Solo cuando el informe crea el caso: un caso existente nunca se modifica.                                             |

Un campo o una opción que Probara no conoce, o que se elimina mientras se procesa el informe, se
omite y se devuelve como advertencia, nunca como un error: el informe registra igualmente cada
resultado. Un campo con el valor vacío se omite sin advertencia. La
[documentación del reporter](https://docs.probara.net/es/developers/ci-integrations/playwright/metadata/) muestra cómo una
prueba define sus parámetros, etiquetas, campos y pasos.

## Gestionar los tokens

En **Tokens de aplicación**, la pestaña **Tokens de acceso** lista cada token activo con quién lo
creó (o **Creado por un usuario eliminado**), cuándo y cuándo se usó por última vez (**Nunca** hasta
su primer informe).

Selecciona **Revocar** en un token, y confírmalo, cuando pueda haberse filtrado o cuando alguien que
podía leerlo deje tu equipo: los pipelines que lo usan dejan de enviar resultados al momento, y no se
puede deshacer. Crea antes un token nuevo para ellos. Como un token de aplicación sobrevive a la
persona que lo creó, rotarlo es decisión tuya: Probara nunca lo revoca por su cuenta.

## Qué puede hacer un token de aplicación

Solo lo que hace el reporter: crear ejecuciones automatizadas, enviar informes (que pueden crear los
casos de prueba y las suites que nombran), añadir adjuntos a sus resultados y cerrar ejecuciones. También
puede leer las claves de casos de una ejecución, que el reporter de Jest usa para ejecutar solo las
pruebas de una ejecución. No puede leer nada más, no puede eliminar adjuntos y no sirve para [Probara MCP](https://docs.probara.net/es/developers/mcp/) ni
para ninguna otra llamada a la API. Para scripts y otros clientes de la API, usa un
[token API](https://docs.probara.net/es/developers/authentication/) personal.

Las ejecuciones, las entradas de actividad y los adjuntos que creó un token de aplicación muestran el
logotipo y el nombre de la aplicación junto al nombre del token — por ejemplo **Playwright ·
e2e-ci** — en la lista de ejecuciones, los resúmenes de la ejecución y del hito, la
[actividad del workspace](https://docs.probara.net/es/guides/workspace/activity/) y la lista de adjuntos.

## Cuando cambia el plan

Si tu organización pasa al plan Free, sus tokens de aplicación se conservan pero Probara los rechaza,
así que los pipelines dejan de enviar resultados; su diálogo lo indica y ofrece **Ver planes**. Aún
puedes ver y revocar los tokens. Vuelven a funcionar en cuanto la organización vuelve a un plan de
pago, sin nada que configurar de nuevo. Las ejecuciones manuales no se ven afectadas.

## Siguiente paso

- [Documentación del reporter](https://docs.probara.net/es/developers/ci-integrations/playwright/) —
  [opciones](https://docs.probara.net/es/developers/ci-integrations/playwright/configuration/),
  [helpers de prueba](https://docs.probara.net/es/developers/ci-integrations/playwright/metadata/),
  [ejecuciones con shards e informes blob](https://docs.probara.net/es/developers/ci-integrations/playwright/sharding/).
- [API de reportes](https://docs.probara.net/es/developers/api-reference/#reportes-de-ci) — el endpoint al que llama el
  reporter, para tus propias herramientas.