# Reporter de Vitest > Envía a Probara cada resultado de tus pruebas de Vitest desde cualquier CI con @probara/vitest-reporter — instalación, configuración y lo que ves en tus ejecuciones. `@probara/vitest-reporter` es un reporter de [Vitest](https://vitest.dev) que envía a Probara cada resultado de una ejecución: cada intento con su estado, su duración y sus errores, vinculado a su caso de prueba, con los pasos, los adjuntos y los enlaces que añaden tus pruebas. Los casos que faltan se crean, y la ejecución se cierra cuando todo ha llegado. Es de código abierto, está publicado en [npm](https://www.npmjs.com/package/@probara/vitest-reporter) en la versión `0.1.0` y vive en el [repositorio probara-sdk](https://github.com/cynch-me/probara-sdk/tree/main/packages/vitest-reporter). Hasta la 1.0, una versión menor puede traer cambios incompatibles: fija la versión ([actualizar el reporter](https://docs.probara.net/es/developers/ci-integrations/vitest/migrating/#actualizar-el-reporter)). ## Qué obtienes - **Un resultado por intento**, incluidos los de `retry` y `repeats`, con el veredicto del propio Vitest: se respeta `test.fails`, `skip` y `todo` se envían como omitidos (un todo con la nota `Todo`), y `context.skip(note)` se omite con su nota. - **Las mismas claves de automatización que `probara import junit`** sobre la salida JUnit de Vitest, así que al dejar la importación JUnit conservas cada caso y su historial. - **Vinculación** por un ID de caso en el título de una prueba o de un `describe` (`SHOP-12 adds an item`) o con `probara.id()`. - **Helpers de prueba** sin nada que configurar, en Node (incluidas las pruebas `test.concurrent`) y en modo navegador: `probara.step()` (anidados, con resultados esperados y datos), `probara.attach()`, `probara.link()`, `probara.issue()`, `probara.parameters()`, y el título, la suite, las etiquetas y los campos de un caso nuevo. - **Los archivos del propio Vitest**: los adjuntos de `context.annotate()`, las capturas de pantalla de los fallos en modo navegador y, con `captureOutput`, la salida de consola de cada intento. - **Ejecuciones** con nombre, entorno, hito, plan de pruebas, configuraciones y etiquetas; una sola ejecución para un job de CI con sharding, fusionada a partir de los blobs; una ejecución por sesión de `--watch`; y **selección de pruebas**: solo las pruebas de una ejecución creada en Probara. - **Nunca rompe tu ejecución de pruebas.** Un problema al reportar se registra, nunca se lanza, y el código de salida de Vitest sigue siendo el de las pruebas. Lo que no se pudo enviar puede guardarse en un archivo y enviarse más tarde. ## Antes de empezar | Necesitas | Por qué | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Node.js 22.12 o posterior | El rango `engines` del paquete. | | Vitest 3.2 o una versión 3.x, 4.x o 5.x posterior | El rango de peer `^3.2.0 \|\| ^4.0.0 \|\| ^5.0.0`: 3.2 es el primer Vitest con anotaciones de prueba, que el reporter lee. Probado en 3.2.7, 4.1.11 y 5.0.2. | | Para el modo navegador, el proveedor de tu versión de Vitest | En la misma versión que `vitest` ([modo navegador](https://docs.probara.net/es/developers/ci-integrations/vitest/browser-mode/)). | | 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, Probara responde `403 forbidden`. | | Un **propietario** o **administrador** de Probara | Solo los propietarios y administradores crean y revocan tokens de aplicación. | | El **ID del Proyecto** al que enviar los resultados | Por ejemplo `SHOP`: una letra mayúscula y después mayúsculas o dígitos. | ## 1. Crea un token de aplicación El reporter se autentica con un [token de aplicación](https://docs.probara.net/es/developers/authentication/#tokens-de-aplicación): un token que pertenece a tu organización, no a una persona. No ocupa ningún puesto y sigue funcionando cuando la persona que lo creó se va. 1. En Probara, abre **Workspace › Integraciones** y selecciona la tarjeta **Vitest**. 2. Abre la pestaña **Tokens de acceso** y selecciona **Crear un token de aplicación**. 3. Escribe un **Nombre del token** con el nombre de lo que lo usa (el repositorio o el pipeline) y selecciona **Crear token**. 4. Selecciona **Copiar token** en **Copia tu nuevo token**. Solo se muestra una vez: guárdalo en ese momento como un secreto de CI llamado `PROBARA_API_TOKEN`. La [guía de la integración con Vitest](https://docs.probara.net/es/guides/integrations/vitest/) cubre la tarjeta, cómo gestionar y revocar los tokens, y qué muestra Probara en las ejecuciones que crea un token de aplicación. ## 2. Instala el reporter ```bash npm install --save-dev @probara/vitest-reporter ``` ## 3. Añádelo a la configuración de Vitest Añade el reporter a los `reporters` de la sección `test`, después de `default` (el que lees en la terminal), con tu ID del Proyecto: ```ts // vitest.config.mts import { defineConfig } from 'vitest/config'; export default defineConfig({ test: { reporters: ['default', ['@probara/vitest-reporter', { projectId: 'SHOP' }]], }, }); ``` Mantén `'default'` en la lista: una lista `reporters` sustituye a la del propio Vitest. La entrada del reporter es la misma en cualquier archivo del que Vitest lea su configuración (`vitest.config.ts`, la sección `test` de `vite.config.ts`...). Puedes omitir `projectId` y definir `PROBARA_PROJECT` en el entorno. El token nunca va en la configuración: la configuración se sube al repositorio, y el reporter lee el token de `PROBARA_API_TOKEN`. ### Nada más que configurar El reporter añade su propio archivo de setup y su runner a cada proyecto de Vitest de la configuración, así que no hay nada que añadir a `setupFiles` ni a `runner`. Los helpers `probara.*`, [`captureOutput`](https://docs.probara.net/es/developers/ci-integrations/vitest/steps-and-attachments/#salida-de-consola) y la [selección de pruebas](https://docs.probara.net/es/developers/ci-integrations/vitest/run-selection/) funcionan sin ninguna otra entrada, y un proyecto de navegador recibe el archivo de setup para navegador de tu versión de Vitest ([modo navegador](https://docs.probara.net/es/developers/ci-integrations/vitest/browser-mode/)). ## 4. Ejecuta tus pruebas con el token Pasa el secreto al paso que ejecuta `vitest`. En GitHub Actions: ```yaml - name: Run Vitest tests run: npx vitest run env: PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }} ``` No hay un paso de subida aparte: el reporter envía los resultados al final del mismo comando. [Proveedores de CI](https://docs.probara.net/es/developers/ci-integrations/vitest/ci-providers/) tiene pipelines completos para GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines, Bitbucket Pipelines y Buildkite. ## Qué ves Sin un token no se envía nada, y las pruebas se ejecutan como siempre: si tampoco hay proyecto, el reporter queda en silencio, así que las ejecuciones locales no envían nada; con un proyecto, avisa en una línea de que el token no está definido. En CI escribe en stderr, en líneas `[probara]`, y termina con el enlace a la ejecución: ```text $ npx vitest run [probara] Sending 3 results of 3 tests (3 passed, 0 failed, 0 skipped, 0 blocked) [probara] Recorded 3 results (2 new cases, 0 unmatched) in R-1 (closed): https://app.probara.net/projects/SHOP/runs/R-1 ``` En Probara, la ejecución aparece en la lista de ejecuciones del proyecto como una ejecución automatizada, con el nombre del build de CI (por ejemplo `Vitest #42`), su rama, su commit y la URL del build. Muestra la aplicación **Vitest** y el nombre del token (por ejemplo **Vitest · unit-ci**) en lugar de una persona. Un job de CI con sharding escribe un blob por shard, con el reporter junto a `blob`, y un job los fusiona en una sola ejecución ([sharding](https://docs.probara.net/es/developers/ci-integrations/vitest/sharding/)): ```bash npx vitest run --shard=1/2 --reporter=blob --reporter=@probara/vitest-reporter npx vitest run --shard=2/2 --reporter=blob --reporter=@probara/vitest-reporter npx vitest --merge-reports ``` Una sesión de `vitest --watch` reporta en una sola ejecución, que queda abierta, cada vez que Vitest vuelve a ejecutar las pruebas ([modo watch](https://docs.probara.net/es/developers/ci-integrations/vitest/configuration/#modo-watch)). ## Cómo se traduce Vitest a Probara | Vitest | En Probara | | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Una prueba, o una fila de `test.each` y `test.for` | Un caso de prueba, encontrado por su clave de automatización o vinculado por un ID de caso | | Cada intento (`retry`) y cada repetición (`repeats`) | Un resultado en la ejecución, con su estado, su duración, su hora de inicio y sus errores | | `skip`, `skipIf`, `runIf`, una prueba que `.only` o `-t` dejan fuera, `todo`, `context.skip()` | Un resultado omitido (`Todo`, o `Skipped: `, en las notas) | | Llamadas a `probara.step()` | Los pasos del resultado, anidados, con su estado, su duración y su error | | `probara.attach()`, archivos de `context.annotate()`, capturas de los fallos, `captureOutput` | Archivos del resultado, o del paso en el que se adjuntaron | | `probara.link()`, `probara.issue()` | Enlaces del resultado | | Otras llamadas `probara.*`, etiquetas de Vitest | El título, la suite, las etiquetas, los campos y los pasos de un caso nuevo; parámetros del resultado | | Un hook `beforeAll` o `afterAll` que lanza un error, un archivo de prueba que no carga | Un resultado fallido, como lo escribe la salida JUnit de Vitest | | El comando `vitest run` | Una ejecución automatizada, con el nombre del build de CI, cerrada al final | Un error no gestionado (un rechazo que ninguna prueba esperó) no es un resultado: una advertencia los cuenta ([errores fuera de una prueba](https://docs.probara.net/es/developers/ci-integrations/vitest/results-and-retries/#errores-fuera-de-una-prueba)). ## Los mismos casos que la importación JUnit El reporter da a cada prueba la clave de automatización que le da `probara import junit` sobre la salida JUnit del propio Vitest (`vitest run --reporter=junit`): el archivo de prueba, y después los bloques `describe` y el título, cada uno tras `>` entre espacios, sin los IDs de caso. Para un `tests/cart.test.ts` cuyo `describe('cart')` contiene `it('SHOP-12 adds an item')` e `it('removes an item')`, y un `tests/login.test.ts` cuyo `describe('login')` contiene `it('logs in with a valid password')`, el reporter envía: ```json [ { "automationKey": "tests/cart.test.ts > cart > adds an item", "status": "passed", "caseDisplayId": "SHOP-12" }, { "automationKey": "tests/cart.test.ts > cart > removes an item", "status": "passed" }, { "automationKey": "tests/login.test.ts > login > logs in with a valid password", "status": "passed" } ] ``` La salida JUnit de Vitest siempre nombra el archivo, así que el valor por defecto, `keyIncludesFile: true`, da las claves de la importación; `keyIncludesFile: false` omite el archivo, para casos cuyas claves se crearon sin él ([claves sin el archivo](https://docs.probara.net/es/developers/ci-integrations/vitest/linking/#sin-el-archivo)). Una prueba conserva su caso y su historial al dejar la importación JUnit, en Vitest 3, 4 y 5 ([migrar desde la importación JUnit](https://docs.probara.net/es/developers/ci-integrations/vitest/migrating/#desde-la-importación-junit)); una importación hecha con la CLI 0.3.0 o anterior daba otra clave a un archivo que no cargaba ([casos creados por una importación anterior](https://docs.probara.net/es/developers/ci-integrations/vitest/migrating/#casos-creados-por-una-importación-anterior)). ## Reportar nunca rompe tu ejecución de pruebas El reporter nunca lanza errores dentro de Vitest ni cambia su código de salida: una prueba fallida hace fallar el comando, un problema al reportar no. Cada problema (un ajuste incorrecto, Probara inalcanzable, un token rechazado) se registra en stderr, nunca con el token, y las pruebas conservan su resultado. Las llamadas `probara.*` tampoco lanzan errores dentro de una prueba: una llamada que Probara no puede usar se omite con una advertencia. No hay ninguna opción para hacer fallar el comando por un error al reportar; para conservar lo que no se pudo enviar, define un [archivo de resultados](https://docs.probara.net/es/developers/ci-integrations/vitest/results-and-retries/#archivo-de-resultados). ## Referencia | Página | Qué cubre | | ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | [Configuración](https://docs.probara.net/es/developers/ci-integrations/vitest/configuration/) | Cada opción, su variable, su tipo y su valor por defecto; precedencia; red, proxies y modo watch | | [Vincular pruebas con casos](https://docs.probara.net/es/developers/ci-integrations/vitest/linking/) | IDs de caso en títulos y describes, `probara.id()`, claves de automatización, `test.each` y `test.for` | | [Metadatos y enlaces](https://docs.probara.net/es/developers/ci-integrations/vitest/metadata/) | Título, suite, comentario, etiquetas, campos, parámetros, ignorar un intento; enlaces; lo que cambia respecto a Jest | | [Pasos y adjuntos](https://docs.probara.net/es/developers/ci-integrations/vitest/steps-and-attachments/) | `probara.step()`, `probara.attach()`, anotaciones de Vitest, capturas, salida de consola, límites | | [Resultados y reintentos](https://docs.probara.net/es/developers/ci-integrations/vitest/results-and-retries/) | Opciones de la ejecución, estados, reintentos y repeticiones, archivo de resultados, asignar fallidos | | [Selección de pruebas](https://docs.probara.net/es/developers/ci-integrations/vitest/run-selection/) | `runCasesOnly`: ejecutar solo las pruebas de una ejecución de Probara | | [Modo navegador](https://docs.probara.net/es/developers/ci-integrations/vitest/browser-mode/) | Los proveedores, los helpers en un navegador, `probara.attach()` y las reglas de archivos de Vite | | [Sharding y proyectos](https://docs.probara.net/es/developers/ci-integrations/vitest/sharding/) | Una ejecución para todos los shards; `projects` de Vitest; varios proyectos de Probara | | [Proveedores de CI](https://docs.probara.net/es/developers/ci-integrations/vitest/ci-providers/) | GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines, Bitbucket Pipelines, Buildkite | | [Solución de problemas](https://docs.probara.net/es/developers/ci-integrations/vitest/troubleshooting/) | Problemas y soluciones, cada línea que registra el reporter, depuración | | [Migración](https://docs.probara.net/es/developers/ci-integrations/vitest/migrating/) | Desde la importación JUnit, Qase, Allure, ReportPortal y TestRail; actualizaciones | Relacionado: [Resumen de integraciones de CI](https://docs.probara.net/es/developers/ci-integrations/) · [Reporter de Playwright](https://docs.probara.net/es/developers/ci-integrations/playwright/) · [Reporter de Jest](https://docs.probara.net/es/developers/ci-integrations/jest/) · [Reporter de Cypress](https://docs.probara.net/es/developers/ci-integrations/cypress/) · [CLI](https://docs.probara.net/es/developers/cli/) · [Guía de la integración con Vitest](https://docs.probara.net/es/guides/integrations/vitest/) · [Código fuente en GitHub](https://github.com/cynch-me/probara-sdk/tree/main/packages/vitest-reporter)