Automatizar sus pruebas de API en integración continua

Un escenario construido en la interfaz se ejecuta tal cual en su pipeline. Esta guía cubre el paso a escala.

Requisitos previos

• Un plan Pro o Enterprise.
• Un token de organización (rstk_…) que hay que colocar en la caja fuerte de secretos de su CI. (La creación de ese token en autoservicio desde el panel de control llegará en breve.)

El principio

RESTORM_TOKEN=$RESTORM_TOKEN restorm \
  --open ./api.restorm \
  --run "Tests de fumée" \
  --headless \
  --all-logs \
  --out run.log \
  --param baseUrl=$BASE_URL

Código de salida 0 = éxito, 1 = fallo del escenario, 2 = error de invocación, 3 = permiso denegado.

Hace falta una pantalla virtual

Restorm es una aplicación de escritorio: incluso sin ventana, necesita un servidor de pantalla. En un runner Linux, añada el prefijo xvfb-run -a.

xvfb-run -a restorm --open ./api.restorm --run "Tests de fumée" --headless

Los secretos

Nunca escriba un secreto en el proyecto. Declare sus variables sensibles con el origen de secretos variable de entorno; la caja fuerte de su CI las inyecta y Restorm las lee. Consulte Secretos.

env:
  API_TOKEN: ${{ secrets.API_TOKEN }}

Parametrizar por entorno

Dos enfoques complementarios:

1. Un parámetro de escenario tipado environment: --param Env=staging. El mismo escenario se ejecuta contra cualquier destino.
2. Parámetros simples: --param baseUrl=…, --param tenant=….

La conversión sigue el tipo declarado del parámetro, y una conversión imposible hace fallar el lanzamiento de inmediato en lugar de ejecutar con un valor incorrecto. Consulte Variables y datos.

Publicar el registro

--out run.log escribe el registro de forma continua. Publíquelo como artefacto, incluso cuando el trabajo falle: es precisamente entonces cuando sirve.

- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: journal-restorm
    path: run.log

Escribir escenarios legibles en CI

Algunos hábitos que lo cambian todo cuando aparece un trabajo en rojo a las 3 de la madrugada:

• Mensajes de aserción explícitos. El campo message de la acción Aserción es lo que aparecerá en el registro: escriba ahí lo que se esperaba.
• Registro en los pasos clave. Sin --all-logs, solo se emiten las entradas de la acción Log: es su hilo narrativo.
• Validación de esquema en lugar de aserción campo a campo. Conecte la salida errors de Validar un esquema a un Log: obtendrá la lista precisa de las infracciones.
• Throw en las salidas else críticas, para que el código de salida refleje el fallo.
• Retry alrededor de las llamadas de red inestables, en lugar de aceptar pruebas intermitentes. Consulte Control.

Limpiar

Encadene la limpieza al puerto done del escenario principal: done espera a que todo el subgrafo haya terminado. Consulte Puertos y enlaces.

Trampas que conviene conocer

Trampa	Solución
El trabajo espera una entrada de datos	Proporcione todos los parámetros con --param; en headless no se puede pedir nada
Una acción Toast no aparece	Es normal: no tiene efecto en headless. Use Log
El servidor MCP no aparece	Es deliberado: sin una pantalla real, nunca arranca
Salida 3	El token o el plan: el mensaje indica cuál de los cuatro casos es
El archivo de proyecto se ha movido	--open acepta una ruta relativa al repositorio: manténgala relativa

Ejemplos completos

Los pipelines de GitHub Actions y GitLab CI están en Ejecución headless y CI.