La aplicación Jest envía a Probara los resultados de tus pruebas de Jest desde cualquier pipeline de CI, con el reporter de Probara para Jest. Cada ejecución de Jest 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 cubre cada opción del reporter y los helpers de prueba.
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 Jest (Jest 29.6 o posterior) que se ejecuta en CI | El reporter se ejecuta con tus pruebas, en el mismo comando npx jest. |
Configurarla
-
En Workspace › Integraciones, selecciona la tarjeta Jest. El diálogo muestra qué puede hacer la aplicación y enlaza a esta guía.
-
Abre la pestaña Tokens de acceso y selecciona Crear un token de aplicación.
-
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.
-
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_TOKENantes de seleccionar Listo. -
Instala el reporter en tu proyecto de Jest:
Terminal window npm install --save-dev @probara/jest-reporter -
Añádelo a los reporters de
jest.config.js, después dedefault(el que lees en la terminal), y sustituye<PROJECT_CODE>por el ID del Proyecto, por ejemploSHOP:jest.config.js module.exports = {reporters: ['default', ['@probara/jest-reporter', { projectId: '<PROJECT_CODE>' }]],};Si tu configuración es un módulo ES —
jest.config.mjs, ojest.config.jsen un paquete con"type": "module"— exporta la misma entrada conexport default:jest.config.mjs export default {reporters: ['default', ['@probara/jest-reporter', { projectId: '<PROJECT_CODE>' }]],}; -
Pasa el secreto a tus pruebas como la variable de entorno
PROBARA_API_TOKENy ejecútalas. Por ejemplo, en GitHub Actions:- name: Run Jest testsrun: npx jestenv:PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }}
El token nunca va en jest.config.js: 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 con jest.retryTimes 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. |
| Pruebas omitidas | Las pruebas omitidas y las pruebas test.todo se registran como omitidas. Cuando ejecutas solo las pruebas de una ejecución, las que no coinciden con ninguno de sus casos no se envían. |
| Errores | El error de un intento fallido, en las notas de su resultado. |
| Pasos | Los pasos que ejecutó un intento con probara.step(), como un árbol con su estado, su duración y su error, debajo del resultado. |
| Adjuntos | Los archivos que adjuntó un intento con probara.attach(), en su resultado — o en el paso en el que se adjuntaron. |
| Enlaces | Los enlaces que añadió un intento con probara.link(), junto al resultado. Las incidencias que nombró con probara.issue() solo se convierten en enlaces cuando la opción del reporter issueUrlTemplate, una URL con %s donde va el id de la incidencia, convierte sus ids en enlaces. |
| Parámetros | Los parámetros que definió un intento con probara.parameters(), como el usuario o el idioma. Un nombre que el caso declara selecciona su caso de ejecución; cualquier otro se muestra solo con el resultado. |
| Casos de prueba nuevos | Una prueba sin caso crea uno, en una suite con el nombre de su archivo de prueba — con keyIncludesFile: false, con el de su bloque describe más externo, cuando lo tiene — salvo que probara.suite() indique otra. |
| 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. |
| Responsables de resultados fallidos | Con la opción assignFailedTo del reporter, un resultado fallido se asigna por turnos a las personas que nombra — solo cuando su caso de la ejecución aún no tiene responsable, y solo a miembros que pueden trabajar en el proyecto. Un responsable existente nunca se reemplaza. |
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. Un correo de assignFailedTo que no
corresponde a ningún miembro que pueda trabajar en el proyecto también se omite, con una advertencia
que solo dice cuántos se omitieron. La
documentación del reporter muestra cómo una prueba define sus
parámetros, etiquetas, campos, pasos y enlaces.
Los mismos casos que una importación JUnit
Si ya envías los resultados de Jest con probara import junit sobre el informe de jest-junit, el
reporter encuentra los mismos casos de prueba: sus claves de automatización son iguales a las de la
importación cuando jest-junit escribió su informe con JEST_JUNIT_ADD_FILE_ATTRIBUTE=true. Si el
informe no tenía el atributo de archivo, define la opción del reporter keyIncludesFile: false. En
ambos casos, al pasar al reporter cada prueba sigue vinculada a su caso y a su historial.
Ejecutar solo las pruebas de una ejecución
Para ejecutar solo las pruebas de una ejecución creada en Probara, añade una vez el archivo de configuración del reporter a tu configuración:
module.exports = { reporters: ['default', ['@probara/jest-reporter', { projectId: '<PROJECT_CODE>' }]], setupFilesAfterEnv: ['@probara/jest-reporter/setup'],};Después, solo en el job que ejecuta las pruebas de esa ejecución, define PROBARA_RUN_CASES_ONLY
con true y PROBARA_RUN_ULID con el ULID de la ejecución. Por ejemplo, en un workflow de GitHub
Actions que inicias a mano con un input run_ulid:
- name: Run the tests of a Probara run run: npx jest env: PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }} PROBARA_RUN_CASES_ONLY: 'true' PROBARA_RUN_ULID: ${{ inputs.run_ulid }}El reporter envía los resultados a esa ejecución y la deja abierta.
Para obtener el ULID, abre la ejecución, selecciona Acciones de la ejecución (el menú de la
cabecera de la ejecución) y elige Copiar ULID de la ejecución; la misma opción está en el menú de
cada ejecución de la lista de ejecuciones. La opción del reporter runCasesOnly: true en
jest.config.js activa la misma selección, pero en todos los jobs: mientras reporta, cada job sin
ULID muestra entonces una advertencia y ejecuta todas las pruebas.
Antes de que empiecen las pruebas, el reporter lee los casos de la ejecución. Una prueba pertenece a
la ejecución cuando su clave de automatización es la de uno de los casos de la ejecución, o cuando su
título o uno de sus bloques describe nombra uno de los casos de la ejecución, por ejemplo
SHOP-12. Una llamada a probara.id() no cuenta: se ejecuta con la prueba, después de la
selección. Leer las claves de casos es la única lectura que puede hacer un token de aplicación.
Jest omite cada una de las demás pruebas, y el reporter no la envía: el resumen de Jest la cuenta
como omitida. Una prueba de la ejecución que el propio archivo omite, con test.skip o test.todo,
se envía igualmente como omitida.
Cuando no se pueden leer los casos de la ejecución, cuando no hay ningún ULID definido, o en un
archivo de prueba en el que no se ejecutó el archivo de configuración, todas las pruebas se ejecutan
y se envían, con una advertencia. El mismo archivo de configuración es el que necesita la opción del
reporter captureOutput para adjuntar la salida de consola de cada prueba a su resultado.
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, cerrar ejecuciones y leer las claves de casos de una ejecución. No puede leer nada más, no puede eliminar adjuntos y no sirve para Probara MCP ni para ninguna otra llamada a la API. Para scripts y otros clientes de la API, usa un token API 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 Jest · unit-ci — en la lista de ejecuciones, los resúmenes de la ejecución y del hito, la actividad del workspace 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 — opciones, helpers de prueba, enlaces y selección de pruebas.
- API de casos de una ejecución — las claves de casos que lee el reporter para ejecutar solo las pruebas de una ejecución.
- API de reportes — el endpoint al que llama el reporter, para tus propias herramientas.