Tester un workflow avec des cas enregistrés

Dans l’éditeur, ouvrez Jeux de test, puis Ajouter un cas. Donnez-lui un nom, renseignez l’événement et les données simulées par port. Le format des données d’un port est celui du sandbox déclaré par son plugin.

Indiquez si l’événement doit déclencher le workflow. Le moteur vérifie son type, le contrat du déclencheur et son filtre. Un événement mal formé fait échouer le cas, même si le filtre devait l’écarter.

Pour un événement retenu, choisissez le statut attendu et les résultats à vérifier. Une assertion comporte un chemin dans le rapport et une opération :

Exemples de chemins : nodes.calcul.0.outputs.value, effects.length, effects.0.payload, validations.0.decision, waits.0.outcome. Les indices désignent une observation ou un élément de liste. Les chemins n’exécutent aucune expression.

Appliquer au jeu de test ajoute les modifications du cas au workflow courant. Lancer les tests vérifie ce graphe en arrière-plan. Chaque résultat peut être ouvert pour lire les erreurs et le rapport complet. Après une modification du graphe ou des cas, relancez les tests : le rapport précédent décrit l’instantané testé.

Enregistrez le brouillon pour conserver les cas. Ils sont dans tests.cases du YAML, suivent ses versions et sont restaurés avec lui. Exemple pour un workflow dont le nœud reponse émet l’entier 42 :

tests:
  cases:
    - id: reponse-nominale
      name: Réponse nominale
      event:
        type: workflow.called
        inputs: {}
      expect:
        routed: true
        status: completed
        assertions:
          - path: nodes.reponse.0.outputs.value
            op: equals
            value: 42

Scénarios et isolation

Les propriétés facultatives d’un cas sont seeds (par port), memory (graines de mémoire), validations (décision par identifiant de nœud : accepted, rejected, timeout), signals (charge utile de reprise par nœud d’attente, ou timeout) et at (horloge moteur ISO 8601).

Sans at, l’horloge moteur reprend event.occurredAt si c’est une date valide, sinon le 1er janvier 2026 à minuit UTC. Les attentes sont traversées et enregistrées. L’horloge des comportements propres aux plugins dépend de leur implémentation.

Chaque cas recrée ses ports sandbox et sa mémoire. Aucun dossier ni mémoire de production n’est chargé. Les écritures sont capturées dans effects ; les agents renvoient des valeurs d’exemple, sans appel à un modèle réel. Un port sans sandbox fait échouer les nœuds qui en dépendent. Les lectures terminologiques peuvent consulter le serveur configuré.

Chaque cas dispose de trente secondes pour répondre ; un dépassement est un échec du cas. Une suite accepte jusqu’à cinquante cas, chacun avec un identifiant unique. Une suite vide ne constitue pas une réussite. Les assertions d’un cas dont routed vaut false ne sont pas exécutées, puisque le workflow ne démarre pas.

Voir aussi la simulation ponctuelle et l’assistant IA.

Pour un workflow à plusieurs déclencheurs, sélectionnez l’entrée de chaque cas dans le champ Déclencheur (trigger: <identifiant> dans le YAML). Le filtre, le contrat d’événement et la branche simulée correspondent tous à cette entrée. Un identifiant absent ou inconnu fait échouer le cas.