Automatiser ses tests d'API en intégration continue

Un scénario construit dans l’interface tourne tel quel dans votre pipeline. Ce guide couvre le passage à l’échelle.

Prérequis

• Un plan Pro ou Enterprise.
• Un jeton d’organisation (rstk_…) à placer dans le coffre à secrets de votre CI. (La création de ce jeton en self-service depuis le tableau de bord arrive prochainement.)

Le principe

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

Code de sortie 0 = succès, 1 = échec du scénario, 2 = erreur d’invocation, 3 = droit refusé.

Un affichage virtuel est nécessaire

Restorm est une application de bureau : même sans fenêtre, elle a besoin d’un serveur d’affichage. Sur un runner Linux, préfixez par xvfb-run -a.

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

Les secrets

N’écrivez jamais un secret dans le projet. Déclarez vos variables sensibles avec la source de secret variable d’environnement ; le coffre de votre CI les injecte, Restorm les lit. Voir Secrets.

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

Paramétrer par environnement

Deux approches complémentaires :

1. Un paramètre de scénario typé environment : --param Env=recette. Le même scénario tourne contre n’importe quelle cible.
2. Des paramètres simples : --param baseUrl=…, --param tenant=….

La conversion suit le type déclaré du paramètre, et une conversion impossible fait échouer le lancement immédiatement plutôt que d’exécuter avec une valeur fausse. Voir Variables et données.

Publier le journal

--out run.log écrit le journal au fil de l’eau. Publiez-le en artefact, y compris quand le job échoue — c’est justement là qu’il sert.

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

Écrire des scénarios lisibles en CI

Quelques habitudes qui changent tout quand un job rouge apparaît à 3 h du matin :

• Messages d’assertion explicites. Le champ message de l’action Assertion est ce qui apparaîtra dans le journal : écrivez-y ce qu’on attendait.
• Journal aux étapes clés. Sans --all-logs, seules les entrées de l’action Log sont émises : c’est votre fil narratif.
• Validation de schéma plutôt qu’assertion champ par champ. Branchez la sortie errors de Valider un schéma sur un Log : vous obtenez la liste précise des violations.
• Throw sur les sorties else critiques, pour que le code de sortie reflète l’échec.
• Retry autour des appels réseau instables, plutôt que d’accepter des tests intermittents. Voir Contrôle.

Nettoyer

Enchaînez le nettoyage sur le port done du scénario principal : done attend que tout le sous-graphe soit terminé. Voir Ports et liaisons.

Pièges à connaître

Piège	Solution
Le job attend une saisie	Fournissez tous les paramètres avec --param ; en headless, rien ne peut être demandé
Une action Toast ne s’affiche pas	C’est normal : elle est sans effet en headless. Utilisez Log
Le serveur MCP n’apparaît pas	C’est voulu : sans affichage réel, il ne démarre jamais
Sortie 3	Le jeton ou le plan — le message précise lequel des quatre cas
Le fichier de projet a bougé	--open accepte un chemin relatif au dépôt : gardez-le relatif

Exemples complets

Les pipelines GitHub Actions et GitLab CI sont dans Exécution headless et CI.