run-acceptance-tests

run-acceptance-tests skill の概要

この skill ができること

run-acceptance-tests skill は、Terraform provider の acceptance test、特に TestAcc プレフィックスを持つテストを正しく実行するための skill です。単に「テストを走らせる」だけでなく、適切な環境で実行し、失敗の意味を読み取り、provider 固有の追加設定が必要な場面を見極めるための、run-acceptance-tests for Acceptance Testing ワークフロー向けに設計されています。

どんな人に向いているか

Terraform provider を扱っていて、ローカル検証、CI のトラブルシュート、あるいは不安定な結果の再現のために実用的な run-acceptance-tests ガイドが必要なら、この run-acceptance-tests skill を使うべきです。特に、対象の acceptance test がすでに決まっていて、フラグや環境変数を手探りで試さずに確実に実行したいときに最も役立ちます。

何が違うのか

この skill は、重要な実行順序にかなり明確な意図を持っています。まずは絞り込んだ go test -run=... を実行し、最初の結果だけでは足りない場合に限って -count=1、-v、TF_LOG=debug、workspace の永続化を足していきます。つまり、run-acceptance-tests skill は、場当たり的に試行錯誤するのではなく、診断の段階を組み込んでいる点で、一般的なプロンプトより優れています。

run-acceptance-tests skill の使い方

skill をインストールする

run-acceptance-tests skill は次のコマンドでインストールします。
npx skills add hashicorp/agent-skills --skill run-acceptance-tests

Terraform provider のワークフローにおける run-acceptance-tests install を評価しているなら、Go テストを実行できること、そして必要なときに provider の認証情報を安全に設定できることを確認してください。この skill は、単独のデモプロジェクトではなく、acceptance testing の文脈を前提にしています。

skill に具体的なテスト対象を渡す

最適な入力は、曖昧な「provider のテストを確認して」ではなく、具体的な TestAcc 名です。たとえば、「TestAccFeatureHappyPath を実行して、足りない env vars を診断して」といった形で依頼するとよいでしょう。この skill は、対象のテスト名、provider、期待される挙動が明確なほど、最も力を発揮します。

最初に見るファイルとシグナルを絞る

まず SKILL.md を起点にし、そのうえでリポジトリ内の README.md、AGENTS.md、metadata.json、さらに存在するなら rules/、resources/、references/、scripts/ フォルダも確認してください。このリポジトリでは主な案内が SKILL.md に集約されているため、大規模な skill ほどファイルツリーの精査は重要ではありませんが、隠れた補助ファイルがないか確認する価値はあります。

実行とデバッグの段階を踏む

通常の実行は、まず TF_ACC=1 go test -run=TestAccFeatureHappyPath を使い、最初は冗長出力なしで進めます。失敗したら、キャッシュ結果を避けるために -count=1 を付けて再実行し、次に -v、その次に TF_LOG=debug を追加し、最後の手段として TF_ACC_WORKING_DIR_PERSIST=1 で Terraform state を各ステップ間で確認します。この段階的なワークフローこそが、run-acceptance-tests の使い方の核心です。

run-acceptance-tests skill の FAQ

これは Terraform provider の acceptance test 専用ですか？

はい。run-acceptance-tests skill は、Terraform provider の acceptance testing、特に TestAcc 命名規則を使う Go テストに限定されています。unit test、一般的な Go test suite、または無関係なインフラ確認には向いていません。

テストに追加の環境変数が必要な場合は？

それは想定内です。この skill は、いくつかの provider では追加の環境変数が必要になることを前提としており、テスト出力から不足している変数を把握して、安全に設定するよう案内します。認証情報や endpoint が不足している場合、それは skill の不備ではなく、run-acceptance-tests ガイドの一部として扱ってください。

普通のプロンプトの代わりに使う必要がありますか？

一度きりの答えではなく、再現可能な手順が欲しいときにこの skill を使ってください。通常のプロンプトでも「このテストを実行して」とは言えますが、run-acceptance-tests skill は、最初の試行が失敗したときや、通ったテストでも検証が必要なときに、どのフラグ、環境変数、エスカレーション手順を使うべきかまで示します。

初心者でも使いやすいですか？

Go コマンドを実行でき、基本的な環境変数を理解していれば、はい、使いやすいです。この skill は、焦点を絞ったコマンドと明確なデバッグ段階から始めることで、初心者の迷いを減らしますが、それでも provider 固有の認証情報、Terraform の挙動、テスト命名規則は把握していることが前提です。

run-acceptance-tests skill をどう改善するか

テストの文脈をもっと具体的に伝える

最も役立つ入力は、正確なテスト名、provider パッケージ、そして再現したい症状です。「acceptance tests を実行して」では広すぎますが、「internal/provider パッケージの TestAccResourceBasic を実行して、足りない TF_LOG の手がかりを調べて」のように伝えれば、skill はより速く適切な判断を下せます。

失敗したという事実だけでなく、失敗の内容を共有する

最初の実行が失敗したら、完全なテスト出力、不足している変数に関するメッセージ、そして -count=1 や -v の追加後に結果が変わったかどうかも含めてください。run-acceptance-tests skill は、実際の失敗の形を与えるほど改善します。なぜなら、provider acceptance test の失敗理由は、認証、リモート API の準備不足、state drift、テストの不安定さなど、さまざまだからです。

デバッグオプションは正しい順番で使う

まずは必要最小限のエスカレーションを頼み、証拠が足りない場合にだけ段階的に広げてください。run-acceptance-tests の使い方としては、通常は単一の絞り込んだ TestAcc 名から始め、verbose output、debug logs、workspace の永続化は、何を確認する必要があるか分かってから追加するのが基本です。

コマンドだけでなく、テスト自体を反復する

通ったテストが意味のあるものか確認したいなら、同じコマンドを繰り返すだけでなく、チェックや手順を 1 つだけ変えて再実行してください。そうすることで、run-acceptance-tests skill は Acceptance Testing でより価値を持ちます。実際に pass したのか、false negative だったのかを切り分けられ、テストのシグナルを継続的に磨けるからです。