Créer des exécutions de test dans Testmo

scripts/testmo_create_runs.py sélectionne les cas correspondant à chaque spécification de filtre et, uniquement avec --create, crée une exécution par spécification via l'API Testmo.

Les écritures modifient l'instance Testmo active. Faites toujours un essai à vide et laissez l'utilisateur examiner avant --create.

Prérequis

• TESTMO_API_KEY exportée dans l'environnement. Référencez-la uniquement par variable — ne jamais afficher, imprimer, journaliser, valider ou passer la valeur en argument de ligne de commande.
• python3 sur PATH. curl est utilisé automatiquement en secours sur les réseaux à inspection TLS ; voir references/tls-inspecting-proxies.md uniquement si cette alternative nécessite une explication.

Chemins

Le script est livré dans le plugin installé, adressez-le toujours via ${CLAUDE_PLUGIN_ROOT}. L'état du shell ne persiste pas entre les commandes, définissez le raccourci dans chaque commande :

SKILL="${CLAUDE_PLUGIN_ROOT}/skills/creating-test-runs"

Les spécifications peuvent résider n'importe où ; passez leurs vrais chemins. Ne stockez jamais une spécification utilisateur dans $SKILL/ — c'est le cache du plugin, que /plugin update écrase.

Workflow

1. Récupérez les spécifications. Utilisez les chemins de spécification fournis, ou écrivez une nouvelle spécification en partant de examples/test-run.template.json, sauvegardée en dehors du plugin. Lisez references/api-reference.md pour connaître les ids derrière les valeurs de champ avant d'écrire ou de déboguer une spécification.
2. Confirmez que la jalonnette existe. L'API ne peut pas créer de jalonnettes ; l'utilisateur les crée dans l'interface Testmo. Liez les exécutions avec --milestone-name "<nom exact>" ou --milestone-id <id>.
3. Essai à vide. Passez --spec une fois par exécution :

   SKILL="${CLAUDE_PLUGIN_ROOT}/skills/creating-test-runs"
   python3 "$SKILL/scripts/testmo_create_runs.py" \
     --spec /path/to/a.json --spec /path/to/b.json \
     --milestone-name "<nom exact de la jalonnette>"

   Une seule spécification imprime aussi la résolution de son dossier, les cas d'exemple et la charge utile de l'exécution.

4. Montrez la sortie de l'essai à vide à l'utilisateur et arrêtez-vous. Pointez chaque ligne dont le STATUS n'est pas ready, la ligne Existing, et tout décompte de cas qui semble aberrant (un grand écart par rapport au dernier cycle indique généralement un dossier ou une étiquette renommés). Attendez une confirmation explicite. N'exécutez jamais l'essai à vide et --create dans le même tour.
5. Créez en réexécutant la commande identique avec --create.
6. Signalez le résultat, y compris chaque exécution listée sous MANUAL STEP 2 REQUIRED — ces exécutions sont inachevées jusqu'à ce que l'utilisateur effectue le passage de l'interface utilisateur dans references/multi-configuration-runs.md.

Lire l'essai à vide

--create refuse le lot entier à moins que chaque ligne soit ready. La ligne Existing lit NOT CHECKED sans jalonnette, et CANNOT CHECK quand l'API masque les liens de jalonnette — dans ce cas, faites vérifier la jalonnette à l'utilisateur dans l'interface Testmo avant de créer.

Si certaines créations échouent, le script les nomme et quitte avec un code non-zéro. Réexécutez avec uniquement les spécifications échouées ; les autres existent déjà et signaleraient désormais DUPLICATE.

Schéma de spécification de filtre

Les clés de niveau supérieur décrivent l'exécution ; les clés sous filters sélectionnent ses cas.

{
  "project_id": 1,
  "run_name": "Password Manager",
  "run_state_id": 7,
  "tags": ["regression"],
  "filters": {
    "folder_paths": ["Web > Password Manager"],
    "test_type_ids": [19, 20],
    "case_state_ids": [4],
    "exclude_automation_type_ids": [10, 23, 24]
  }
}

Niveau supérieur : project_id et run_name sont requis ; chaque spécification dans une invocation doit partager le même project_id. Optionnel : run_state_id (défaut 7, En cours), milestone_id (remplacé par les drapeaux de jalonnette), config_id (uniquement pour les exécutions de même nom divisées par Configuration Testmo), tags (étiquette l'exécution — ne sélectionne pas les cas), note.

Sous filters chaque clé est optionnelle ; les clés sont combinées avec ET, les valeurs au sein d'une clé avec OU :

• tags — sélectionnez les cas portant ces noms ou ids d'étiquette. Préférez les ids quand un nom est dupliqué.
• folder_paths / folder_ids — dossiers et leurs descendants (include_subfolders: false pour exact).
• test_type_ids, team_ids — l'ensemble du cas doit croiser la liste.
• case_state_ids — par ex. [4] pour Actif.
• automation_type_ids / exclude_automation_type_ids — pour manuel uniquement, excluez [10, 23, 24].
• has_automation — booléen.

Une exécution définie purement par une étiquette doit définir filters.tags ; définir uniquement le niveau supérieur tags ne sélectionne rien. Un bloc filters vide ou manquant correspond à chaque cas du projet, vérifiez toujours le décompte de l'essai à vide.

Gardez run_name à la zone brute (par ex. "Password Manager") ; la version provient de la jalonnette et la plateforme de config_id.