Selección de pruebas en Cypress

Alguien crea una ejecución en Probara (los casos de una versión, de un plan de pruebas, los que fallaron ayer) y el pipeline ejecuta exactamente esas pruebas. Con runCasesOnly, el plugin lee los casos de la ejecución antes de la primera spec, el archivo de soporte omite cada prueba que no pertenece a ninguno de ellos, y los resultados de las pruebas que se ejecutaron van a esa ejecución, que queda abierta.

Camino rápido

1. Registra el plugin y carga el archivo de soporte (primeros pasos). La selección necesita ambos; sin las variables de abajo, no seleccionan nada.
2. En el job que ejecuta las pruebas de una ejecución, define PROBARA_RUN_CASES_ONLY=true y PROBARA_RUN_ULID con el ULID de la ejecución. En Probara, 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.
3. Revisa la ejecución en Probara: sus casos tienen los resultados, y la ejecución queda abierta para quien la creó.

$ PROBARA_RUN_CASES_ONLY=true PROBARA_RUN_ULID=01J9Z3K4M5N6P7Q8R9S0T1V2W3 npx cypress run
[probara] Ran only the tests of run 01J9Z3K4M5N6P7Q8R9S0T1V2W3: 2 of 3 tests match its cases; 1 skipped and not reported

En GitHub Actions, un workflow que se inicia a mano con el ULID de la ejecución como input:

on:
  workflow_dispatch:
    inputs:
      run_ulid:
        description: The ULID of the Probara run to run the tests of
        required: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 22
      - run: npm ci
      - name: Run the tests of a Probara run
        run: npx cypress run
        env:
          PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }}
          PROBARA_RUN_CASES_ONLY: 'true'
          PROBARA_RUN_ULID: ${{ inputs.run_ulid }}

Actívala por job, con las variables: runCasesOnly: true en la configuración de Cypress la activa en todos los jobs, y un job sin ULID muestra entonces una advertencia y ejecuta todas las pruebas.

Qué pruebas pertenecen a la ejecución

Una prueba pertenece a la ejecución cuando se cumple una de estas condiciones, que se comprueban para cada prueba antes de que se ejecute:

La prueba	Ejemplo
Su clave de automatización es la de uno de los casos de la ejecución	Un caso que creó el reporter o probara import junit
Su título o el de uno de sus describe nombra uno de los casos de la ejecución	it('SHOP-12 adds an item'), describe('SHOP-12 Cart')

• probara.id() no cuenta: se ejecuta con la prueba, después de la selección. Nombra el caso en un título (vincular).
• Las claves son las del reporter: la ruta de la spec (con keyIncludesFile) y el título completo. Una batería cuyas claves se renombraron después de crear la ejecución no coincide por clave en absoluto.
• Un caso de la ejecución sin prueba simplemente no recibe resultado: el registro solo cuenta las pruebas.

Qué se reporta

Prueba	Se ejecuta	Se reporta
Pertenece a la ejecución	Sí	Sí, en la ejecución, con cada intento
Pertenece a la ejecución, pero es it.skip	No	Sí, como omitida
No pertenece a ningún caso de la ejecución	No	No: se omite y queda fuera de la ejecución

Una prueba fuera de la ejecución se omite, no se ejecuta: el archivo de soporte pregunta al plugin por cada prueba en un beforeEach raíz, y llama a this.skip() en una prueba que la ejecución no incluye. No se reporta, así que no añade nada a la ejecución; el resumen propio de Cypress la cuenta como omitida.

Qué se sigue ejecutando

Cypress carga una spec antes de que la selección pueda omitir sus pruebas, así que una spec sin pruebas de la ejecución sigue ejecutando el código de nivel superior de su archivo (lo que importa y lo que prepara) y los hooks before y after de la raíz del archivo. Sus pruebas se omiten; el archivo no se omite entero.

Cuando eso es costoso, pasa además a Cypress solo las specs de las pruebas de la ejecución:

PROBARA_RUN_CASES_ONLY=true PROBARA_RUN_ULID=01J9Z3K4M5N6P7Q8R9S0T1V2W3 npx cypress run --spec 'cypress/e2e/{cart,checkout}.cy.js'

Pon el glob entre comillas, para que la shell no lo expanda antes.

Cuando no puede seleccionar

La selección nunca rompe la ejecución de pruebas: cuando no puede saber qué pruebas pertenecen a la ejecución, todas las pruebas se ejecutan y se reportan, con una advertencia.

Qué pasa	La advertencia
No hay run.ulid ni PROBARA_RUN_ULID	runCasesOnly needs the run whose tests to run: set run.ulid or PROBARA_RUN_ULID. Every test runs and is reported
Los casos de la ejecución no se pueden leer	runCasesOnly: could not read the cases of the run <ULID> (<reason>). Every test runs and is reported
Falta el archivo de soporte	runCasesOnly needs the support file: require('@probara/cypress-reporter/support') in the Cypress support file, or every test runs and is reported
Ninguna prueba coincide con un caso de la ejecución	No test matches the cases of the run <ULID>: every test was skipped, and none is reported

Los casos no se pueden leer con un ULID incorrecto, un token de otra organización o Probara inalcanzable: el motivo está en la línea. Sin el plugin no hay nadie que lea los casos ni que responda al navegador, así que también se ejecutan y se reportan todas las pruebas.

Cuando ninguna prueba coincide, no se envía nada y la ejecución queda como estaba: comprueba que el ULID es el de la ejecución que querías.

Configuraciones

• Pipelines repartidos: cada máquina lee los casos de la ejecución y ejecuta su parte de las pruebas seleccionadas.
• Una petición más: leer los casos es una petición antes de la primera spec, 200 casos por página (red), y después un cy.task() por prueba, que el plugin responde al momento. Es la única lectura que puede hacer un token de aplicación: el endpoint de las claves de casos de una ejecución.
• statusFilter: ['skipped'] deja fuera también las pruebas de la ejecución que son it.skip.

Relacionado: Configuración · Una ejecución existente · Solución de problemas · Fuente: run-selection.md