run-acceptance-tests
par hashicorpGuide du skill run-acceptance-tests pour les tests d’acceptation des providers Terraform. Utilisez-le pour lancer des tests `TestAcc` ciblés, gérer de façon sécurisée les variables d’environnement requises et déboguer les échecs avec un workflow clair, étape par étape.
Ce skill obtient 78/100 : c’est donc une fiche solide mais ciblée pour les utilisateurs du répertoire. Elle fournit assez de consignes de workflow explicites pour lancer correctement les tests d’acceptation et limiter les hésitations, même si elle ne constitue pas un guide opérationnel très large ni particulièrement abouti.
- Déclenchement explicite des tests d’acceptation Terraform, avec le préfixe `TestAcc` et l’exigence `TF_ACC=1`.
- Workflow concret pour exécuter puis diagnostiquer les tests : relancer avec `-count=1`, puis `-v`, puis `TF_LOG=debug`, avec en option la persistance du workspace.
- Conseils de remédiation utiles quand les variables d’environnement propres au provider manquent, ce qui aide les agents à récupérer après des échecs d’exécution fréquents.
- Un usage unique et assez étroit : ce skill vise les tests d’acceptation des providers Terraform, pas l’automatisation de tests au sens large.
- Aucun script d’appui, aucune référence ni aucun exemple dans l’arborescence du dépôt ; les agents doivent donc s’appuyer uniquement sur les consignes rédigées.
Vue d’ensemble de la skill run-acceptance-tests
Ce que fait cette skill
La skill run-acceptance-tests vous aide à exécuter correctement les tests d’acceptation d’un provider Terraform, en particulier les tests nommés avec le préfixe TestAcc. Elle est conçue pour le workflow run-acceptance-tests de l’Acceptance Testing, où l’enjeu n’est pas seulement de « lancer un test », mais de l’exécuter dans le bon environnement, d’interpréter les échecs et de savoir quand une configuration spécifique au provider est nécessaire.
À qui s’adresse-t-elle
Utilisez la skill run-acceptance-tests si vous travaillez sur un provider Terraform et que vous avez besoin d’un guide pratique run-acceptance-tests pour la validation locale, le débogage en CI ou la reproduction d’un résultat instable. Elle est surtout utile lorsque vous avez déjà un test d’acceptation précis en tête et que vous cherchez une manière fiable de l’exécuter sans deviner les flags ni les variables d’environnement.
Ce qui la distingue
Cette skill est prescriptive sur l’ordre qui compte : commencer par une invocation ciblée de go test -run=..., puis n’ajouter -count=1, -v, TF_LOG=debug et la persistance du workspace que si le premier essai ne suffit pas. Cela rend la skill run-acceptance-tests plus utile qu’une invite générique, car elle encode une véritable échelle de diagnostic au lieu de vous laisser improviser.
Comment utiliser la skill run-acceptance-tests
Installer la skill
Installez la skill run-acceptance-tests avec :
npx skills add hashicorp/agent-skills --skill run-acceptance-tests
Si vous évaluez l’installation de run-acceptance-tests dans un workflow de provider Terraform, vérifiez que votre environnement peut exécuter des tests Go et que vous pouvez définir les identifiants du provider de façon sûre lorsque c’est nécessaire. La skill suppose un contexte d’Acceptance Testing, pas un simple projet de démonstration autonome.
Donner à la skill une cible de test précise
L’entrée la plus utile est un nom TestAcc concret, pas une demande floue du type « vérifie les tests du provider ». Par exemple, demandez quelque chose comme : « Lance TestAccFeatureHappyPath et diagnostique les variables d’environnement manquantes. » La skill fonctionne mieux lorsque le nom du test cible, le provider et le comportement attendu sont explicites.
Commencer par les bons fichiers et les bons signaux
Commencez par SKILL.md, puis inspectez README.md, AGENTS.md, metadata.json, ainsi que les dossiers d’appui rules/, resources/, references/ ou scripts/ s’ils existent. Dans ce dépôt, l’essentiel des consignes est concentré dans SKILL.md, donc l’inspection de l’arborescence compte moins que dans des skills plus volumineuses, mais elle reste utile pour vérifier qu’il n’existe pas de fichiers d’aide cachés.
Suivre la progression d’exécution et de débogage
Pour une exécution normale, utilisez TF_ACC=1 go test -run=TestAccFeatureHappyPath et gardez d’abord une sortie non verbeuse. Si le test échoue, relancez avec -count=1 pour éviter les résultats mis en cache, puis ajoutez -v, ensuite TF_LOG=debug, et seulement après envisagez TF_ACC_WORKING_DIR_PERSIST=1 pour inspecter l’état Terraform entre les étapes. Ce workflow par paliers est le cœur de l’usage de run-acceptance-tests.
FAQ sur la skill run-acceptance-tests
Est-ce réservé aux tests d’acceptation des providers Terraform ?
Oui. La skill run-acceptance-tests est limitée aux tests d’acceptation de providers Terraform, en particulier aux tests Go qui suivent la convention de nommage TestAcc. Elle n’est pas destinée aux tests unitaires, aux suites de tests Go génériques ni aux vérifications d’infrastructure sans lien avec ce cadre.
Que faire si le test nécessite des variables d’environnement supplémentaires ?
C’est prévu. La skill part explicitement du principe que certains providers exigent des variables d’environnement additionnelles et vous demande de faire remonter les variables manquantes depuis la sortie du test, puis de les configurer de manière sécurisée. Si des identifiants ou des endpoints manquent, considérez cela comme faisant partie du guide run-acceptance-tests, pas comme une défaillance de la skill.
Ai-je besoin de cette skill à la place d’une invite classique ?
Utilisez cette skill lorsque vous voulez une procédure reproductible, pas seulement une réponse ponctuelle. Une invite classique peut vous dire de lancer un test ; la skill run-acceptance-tests vous indique quels flags, quelles variables d’environnement et quelles étapes d’escalade employer quand le premier essai échoue ou quand un test qui passe doit encore être vérifié.
Est-elle adaptée aux débutants ?
Oui, à condition de savoir déjà exécuter des commandes Go et de comprendre les variables d’environnement de base. La skill réduit les hésitations des personnes débutantes en partant d’une commande ciblée et d’une montée en débogage claire, mais elle suppose encore que vous sachiez reconnaître les identifiants propres au provider, le comportement de Terraform et les conventions de nommage des tests.
Comment améliorer la skill run-acceptance-tests
Fournir un contexte de test plus solide
Les entrées les plus utiles sont le nom exact du test, le package du provider et le symptôme que vous essayez de reproduire. « Lance les tests d’acceptation » est trop vague ; « Lance TestAccResourceBasic dans le package internal/provider et cherche une piste TF_LOG manquante » donne à la skill assez de contexte pour choisir rapidement la bonne approche.
Partager les détails de l’échec, pas seulement son statut
Si le premier essai échoue, fournissez la sortie complète du test, les messages de variables manquantes et indiquez si le résultat a changé après -count=1 ou -v. La skill run-acceptance-tests devient plus efficace lorsque vous lui donnez la forme réelle de l’échec, car les tests d’acceptation de provider échouent souvent pour des raisons différentes : authentification, disponibilité de l’API distante, dérive d’état ou instabilité du test.
Utiliser les options de débogage dans le bon ordre
Demandez d’abord l’escalade minimale nécessaire, puis élargissez seulement si les indices l’exigent. Pour l’usage de run-acceptance-tests, cela signifie généralement commencer par un seul nom TestAcc ciblé, puis n’ajouter la sortie verbeuse, les journaux de debug ou la persistance du workspace qu’après avoir compris ce que vous devez inspecter.
Faire évoluer le test, pas seulement la commande
Si vous devez confirmer qu’un test qui passe est réellement significatif, modifiez une seule vérification ou une seule étape, puis relancez-le au lieu de répéter la même commande. Cela rend la skill run-acceptance-tests plus précieuse pour l’Acceptance Testing, car elle vous aide à distinguer un vrai succès d’un faux négatif et à renforcer progressivement le signal du test.