Reporter de Vitest

@probara/vitest-reporter es un reporter de Vitest 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 en la versión 0.1.0 y vive en el repositorio probara-sdk. Hasta la 1.0, una versión menor puede traer cambios incompatibles: fija la versión (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).
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: 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 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

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:

// 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 y la selección de pruebas 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).

4. Ejecuta tus pruebas con el token

Pasa el secreto al paso que ejecuta vitest. En GitHub Actions:

- 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 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:

$ 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):

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).

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: <note>, 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).

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:

[
  {
    "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). 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); 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).

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.

Referencia

Página	Qué cubre
Configuración	Cada opción, su variable, su tipo y su valor por defecto; precedencia; red, proxies y modo watch
Vincular pruebas con casos	IDs de caso en títulos y describes, probara.id(), claves de automatización, test.each y test.for
Metadatos y enlaces	Título, suite, comentario, etiquetas, campos, parámetros, ignorar un intento; enlaces; lo que cambia respecto a Jest
Pasos y adjuntos	probara.step(), probara.attach(), anotaciones de Vitest, capturas, salida de consola, límites
Resultados y reintentos	Opciones de la ejecución, estados, reintentos y repeticiones, archivo de resultados, asignar fallidos
Selección de pruebas	runCasesOnly: ejecutar solo las pruebas de una ejecución de Probara
Modo navegador	Los proveedores, los helpers en un navegador, probara.attach() y las reglas de archivos de Vite
Sharding y proyectos	Una ejecución para todos los shards; projects de Vitest; varios proyectos de Probara
Proveedores de CI	GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines, Bitbucket Pipelines, Buildkite
Solución de problemas	Problemas y soluciones, cada línea que registra el reporter, depuración
Migración	Desde la importación JUnit, Qase, Allure, ReportPortal y TestRail; actualizaciones

Relacionado: Resumen de integraciones de CI · Reporter de Playwright · Reporter de Jest · Reporter de Cypress · CLI · Guía de la integración con Vitest · Código fuente en GitHub