Tutorial: ejecutar pruebas desde la CLI

Esta página muestra cómo ejecutar un conjunto de pruebas de UiPath Test Manager desde la CLI como parte de un proceso de CI y, lo que es más importante, cómo leer el veredicto correctamente. La herramienta uip tm divide una ejecución de prueba en tres verbos por una razón; utilizar solo uno de ellos puede producir una compilación aprobada incluso cuando las pruebas han fallado.

La regla de oro: iniciar → esperar → verificar

Ningún verbo uip tm único sale distinto de cero porque las pruebas fallaron. Conseguir que un proceso falle en una ejecución de prueba roja requiere tres comandos:

1. Iniciar — uip tm testsets run. Pone en cola la ejecución y sale de 0 tan pronto como Orchestrator acepte la solicitud. Status: "Running" en la respuesta refleja el estado en el lanzamiento, no el resultado final.
2. Bloquear : uip tm wait. Sondea hasta que la ejecución alcanza un estado terminal (Passed, Failed, Cancelled). Sale de 0 cuando alcanza cualquier estado terminal, porque "finalizado" es la señal de éxito para wait. Salidas 2 en --timeout (una reutilización específica del dominio de la ranura de error de autenticación, por lo que los scripts pueden ramificarse en "tardó demasiado" sin analizar el texto).
3. Verificar : uip tm report get. Lee Data.Failed (y Passed, Skipped, PassRate). Sale de 0 siempre que obtiene correctamente el resumen, independientemente de si se aprobó/falló: el script es responsable de convertir Data.Failed > 0 en una salida distinta de cero.

Existen patrones de acceso directo (uip or jobs start --wait-for-completion, por ejemplo, espera+verificar en un solo trabajo), pero no para conjuntos de prueba. Escribe siempre los tres pasos.

Fragmento mínimo viable

#!/usr/bin/env bash
set -euo pipefail

# 1. Launch
EXECUTION_ID=$(uip tm testsets run \
  --test-set-key DEMO:10 \
  --output-filter "Data.ExecutionId" \
  --output plain)

# 2. Block (default timeout: 30 min; adjust with --timeout)
if ! uip tm wait \
  --execution-id "$EXECUTION_ID" \
  --project-key DEMO \
  --timeout 1800; then
  code=$?
  if [ "$code" -eq 2 ]; then
    echo "test run did not finish within 30 minutes" >&2
    exit 2
  fi
  echo "wait failed (exit $code)" >&2
  exit "$code"
fi

# 3. Verify
FAILED=$(uip tm report get \
  --execution-id "$EXECUTION_ID" \
  --project-key DEMO \
  --output-filter "Data.Failed" \
  --output plain)

if [ "$FAILED" -gt 0 ]; then
  echo "$FAILED test case(s) failed" >&2
  exit 1
fi

echo "all tests passed"

--output plain el valor básico para un resultado de filtro escalar; esta es la forma más segura de capturar un campo en una variable de shell sin analizar JSON. Consulta Patrones de scripts: leer valores fuera del sobre.

Seleccionar entradas para los comandos

uip tm testsets run necesita la clave del conjunto de pruebas, no su UUID. La clave tiene la forma <ProjectKey>:<Number> — por ejemplo, DEMO:10. Dos formas de encontrarlo:

# From the Test Manager UI — it is the "Key" column in the test set list.

# Or from the CLI:
uip tm testsets list --project-key DEMO --filter smoke \
  --output-filter "Data[*].{key:TestSetKey, name:Name}"

--project-key es obligatorio en list; run deriva el proyecto del prefijo de la clave del conjunto de pruebas (DEMO:10 → proyecto DEMO).

Si necesitas el UUID numérico para uip tm executions list --test-set-id, ese es el campo Id en la misma salida de lista, no el TestSetKey.

Elegir qué casos se ejecutan

uip tm testsets run --execution-type controla qué casos de prueba dentro del conjunto se ejecutan:

• automated predeterminado) : solo casos de prueba automatizados.
• manual : solo casos de prueba manuales.
• mixed — ambos.
• none — sin filtro de tipo.

Para CI, mantenga el valor predeterminado (automated): los casos manuales requieren que un humano los marque como aprobado/reprobado y se ubicarán en InProgress hasta --timeout.

Pasar anulaciones de parámetros

Si el conjunto de pruebas expone parámetros (por ejemplo, una URL de destino o un ID de cuenta), anúlalos en el lanzamiento con --input-path:

cat > ./params.json <<'EOF'
[
  {"name": "TargetUrl", "type": "String", "value": "https://staging.example.com"},
  {"name": "AccountId", "type": "String", "value": "acme-staging"}
]
EOF

uip tm testsets run --test-set-key DEMO:10 --input-path ./params.json

Las anulaciones se comparan con las definiciones de parámetros actuales del conjunto de pruebas por name (no distingue entre mayúsculas y minúsculas) y, cuando está presente, type. Si el servidor no informa de definiciones de parámetros, las entradas se envían tal cual.

Leer el veredicto en detalle

uip tm report get es el lector de resumen. La salida predeterminada te da el cuadro de mando; pasa --query (un filtro de estilo jq) para extraer un subconjunto en una llamada:

# Pretty scorecard
uip tm report get --execution-id "$EXECUTION_ID" --project-key DEMO

# Script-friendly — JSON with just the counts
uip tm report get --execution-id "$EXECUTION_ID" --project-key DEMO \
  --query '{total: .TotalTests, passed: .Passed, failed: .Failed}'

El sobre Data tiene estos campos (esquema completo en la referenciareport get ):

• TotalTests, Passed, Failed, Skipped, PassRate ("80%"), Duration (HH:MM:SS).
• FailedTests : una entrada por caso de prueba fallido, con TestCaseName y una cadena Error (ya sea el campo info del registro o una lista concatenada de mensajes de aserción fallidos).

Cuando necesites un archivo JUnit-XML que el panel de prueba de tu CI pueda ingerir, utiliza uip tm result download en lugar de (o junto a) report get.

Aparición de casos fallidos en registros de CI

Convierte la matriz FailedTests en una línea legible por humanos por fallo antes de salir del proceso:

if [ "$FAILED" -gt 0 ]; then
  uip tm report get \
    --execution-id "$EXECUTION_ID" \
    --project-key DEMO \
    --output-filter "Data.FailedTests[*].[TestCaseName, Error]" \
    --output plain >&2
  echo "$FAILED test case(s) failed" >&2
  exit 1
fi

Para un análisis de fallos más profundo (detalles aserción por aserción en un solo caso fallido), utiliza uip tm testcaselogs list-assertions en los ID de registro devueltos por uip tm executions testcaselogs list --only-failed.

Reintentar casos escamosos

Si una ejecución tiene fallos que pueden ser escamosos (tiempo, entorno), reintenta solo los casos fallidos en su lugar:

uip tm executions retry \
  --execution-id "$EXECUTION_ID" \
  --project-key DEMO

uip tm executions retry reutiliza el mismo ID de ejecución: no se crea uno nuevo. Si no hay fallos al reintentar, imprime un mensaje informativo y sale de 0 (intencionalmente no es un error).

Después de retry, vuelve a pasar por wait + report get en el mismo ID de ejecución.

Errores comunes

• Analizando la salida testsets run para decidir si se aprueba/no se aprueba. El campo Status en el lanzamiento suele ser Running : significa que la ejecución se puso en cola, no que se pasaron todas las pruebas. Llama siempre wait y luego report get.
• Olvidando el --timeout el wait. El valor predeterminado es 1800 segundos (30 minutos). Pase 0 para esperar indefinidamente (rara vez lo que desea en CI); pasar un número mayor para suites largas.
• Tratando la salida 2 de wait como un error de autenticación. En wait específicamente, 2 significa tiempo de espera, no AuthenticationError — consulta uip tm wait códigos de salida.
• Uso de verbos testsets para crear pruebas. Los casos de prueba y sus enlaces a automatizaciones de Orchestrator provienen de uip tm testcases; testsets solo los agrupa.

Ejemplo completo de CI-ready

Un fragmento de bash para un paso del proceso: la compilación falla cuando falla cualquier prueba, se agota el tiempo de espera o se producen errores:

#!/usr/bin/env bash
set -euo pipefail

TEST_SET_KEY="${TEST_SET_KEY:?TEST_SET_KEY is required}"
PROJECT_KEY="${PROJECT_KEY:?PROJECT_KEY is required}"
TIMEOUT="${TEST_TIMEOUT:-1800}"

EXECUTION_ID=$(uip tm testsets run \
  --test-set-key "$TEST_SET_KEY" \
  --output-filter "Data.ExecutionId" \
  --output plain)

echo "started execution $EXECUTION_ID" >&2

if ! uip tm wait \
  --execution-id "$EXECUTION_ID" \
  --project-key "$PROJECT_KEY" \
  --timeout "$TIMEOUT"; then
  code=$?
  case "$code" in
    2) echo "execution $EXECUTION_ID did not finish within ${TIMEOUT}s" >&2; exit 2 ;;
    *) echo "wait failed with exit $code" >&2; exit "$code" ;;
  esac
fi

# Get the scorecard and the names of any failed cases in one shot
uip tm report get \
  --execution-id "$EXECUTION_ID" \
  --project-key "$PROJECT_KEY"

FAILED=$(uip tm report get \
  --execution-id "$EXECUTION_ID" \
  --project-key "$PROJECT_KEY" \
  --output-filter "Data.Failed" \
  --output plain)

if [ "$FAILED" -gt 0 ]; then
  echo "$FAILED test case(s) failed" >&2
  exit 1
fi

echo "all tests passed"

Ejecuta este script después de tu paso de implementación de la solución en cualquiera de las recetas de CI. La única configuración específica de entorno es TEST_SET_KEY / PROJECT_KEY : establécelas por entorno en el proceso, y el mismo script promueve limpiamente en dev/stage/prod.

Ver también

• Información generaluip tm : la superficie de comando completa.
• uip tm testsets run, uip tm wait, uip tm report get : los tres verbos utilizados anteriormente.
• uip tm result download — Exportación XML JUnit para paneles de CI.
• Patrones de scripting : sondeo, filtrado JSON, procesos idempotentes.
• Códigos de salida : el contrato compartido y el wait específico del dominio de 2.