provider-test-patterns

provider-test-patterns の概要

provider-test-patterns は、terraform-plugin-testing と Plugin Framework を使うチーム向けの、Terraform provider の受け入れテスト作成スキルです。汎用プロンプトよりも試行錯誤を減らしながら、provider テストの書き方、レビュー、デバッグを進められます。特に、適切な TestCase、TestStep、state チェック、plan チェック、import 検証、sweeper の設定が必要な場面で効果を発揮します。

最適な利用場面と解決したい仕事

provider-test-patterns スキルを使うべきなのは、実際の課題が「provider リソース向けの信頼できる受け入れテストパターンが必要で、このケースに合うテスト形がどれか知りたい」という場合です。とくに provider のバックエンド開発では、難しいのは構文だけではなく、正しいアサーション戦略とライフサイクル全体のカバレッジを選ぶことです。

何が得意か

provider-test-patterns スキルが特に強いのは、次のような判断が必要なときです。

• plan、apply、refresh、destroy をまたぐテストのライフサイクルフロー
• TestCase と TestStep の構成
• ConfigStateChecks、plancheck、CompareValue
• ImportStateKind を使った import テスト
• sweeper とクリーンアップの安全性
• basic、update、disappears、validation、regression といったシナリオパターン
• echoprovider パターンを使った一時的リソースのテスト

強く推奨できる導入ケース

provider-test-patterns は、Terraform provider の受け入れテストに直結する、意見のあるパターンを使いたいときに導入する価値があります。特に Plugin Framework で作業しているバックエンド開発チームには相性が良いです。必要なチェックを落とす、誤ったアサーション型を使う、保守しにくい構造でテストを書く、といったリスクが主な問題なら、一般的なプロンプトより適しています。

provider-test-patterns スキルの使い方

インストールしてコンテキストに読み込む

まずは、使っている skill manager のリポジトリ導入フローに従ってインストールし、最初に SKILL.md を開いてください。上流のスキルには独自の install コマンドは定義されていないため、実務上の provider-test-patterns install は、エージェントの skills ワークフローでスキルを追加し、そのうえでスキル本体と補助リファレンスを読むことを指します。

コードではなく、まずテスト形から始める

provider-test-patterns usage の最良の進め方は、コードを頼む前にシナリオを説明することです。次の点を明示してください。

• リソース種別とライフサイクル段階
• basic、update、import、disappears、validation、regression のどれをカバーするか
• state や plan で何をアサートすべきか
• sweeper によるクリーンアップが必要か
• 一時的リソースを含むケースかどうか

これだけ揃えば、通常の config チェック、statecheck、plancheck、ステップをまたぐ比較のどれを選ぶべきかを、スキルが判断しやすくなります。

先に読むべきファイル

素早く使い始めるなら、次の順で読み進めるのがおすすめです。

1. SKILL.md — 主要なパターンセットとライフサイクルのガイダンス
2. references/checks.md — statecheck、plancheck、既知の値、比較器
3. references/ephemeral.md — リソースが ephemeral である場合、または echoprovider を使う場合
4. references/sweepers.md — リソースの取り残しが懸念される場合

良いプロンプトの形

provider-test-patterns に投げるプロンプトは、リソース、失敗モード、望むアサーション方式を含めるのが理想です。たとえば、次のように書けます。

Write an acceptance test for example_widget update behavior. I need a TestStep sequence that verifies the name changes, the old value is preserved until refresh, and the final state matches the new config. Use CompareValue if that is the right fit.

これは「テストを書いて」よりずっと強い依頼です。単なる話題ではなく、スキルに判断のゴールを与えられるからです。

provider-test-patterns スキル FAQ

provider-test-patterns は Terraform provider エンジニア専用ですか？

ほぼその通りです。Terraform provider の受け入れテスト向けに設計されており、state、plan、cleanup の挙動を確実にカバーしたい provider-test-patterns for Backend Development で特に役立ちます。

terraform-plugin-testing をすでに知っている必要がありますか？

いいえ。ただし、このスキルはそのエコシステムで作業していることを前提にしています。初心者でも、テスト構造の迷いを減らせるので有用です。ただし、細部は参照ドキュメントと既存の provider のテスト慣習で確認する必要があります。

普通のプロンプトと何が違いますか？

普通のプロンプトでもそれらしいテストファイルは出せますが、アサーションの選び方が重要な場面では provider-test-patterns のほうが役立ちます。テストの本当の目的に応じて、ConfigStateChecks、plan チェック、destroy チェック、import state 検証、sweeper パターンのどれを使うべきかを整理できます。

使わないほうがよいのはどんなときですか？

汎用の unit test、Terraform と関係のない Go のテスト、あるいは構文だけをすぐ確認したい質問には向きません。Terraform provider の受け入れテストを使っていないなら、パターンと制約がこのワークフロー固有なので、適合性は低いです。

provider-test-patterns スキルをどう改善するか

足りないテスト情報を先に出す

provider-test-patterns の結果をよくする最善策は、テスト設計を変える最小限の情報を最初に渡すことです。

• リソース名と provider パッケージ
• リソースが作成、更新、import、destroy のどれに関わるか
• どの属性を正確にチェックすべきか
• 値が static、computed、sensitive、cross-step のどれか
• クリーンアップや leak recovery をテストに含める必要があるか

防ぎたい失敗を明示する

何が壊れうるかを伝えると、スキルはより適切なアサーションを選べます。たとえば、次のような問題を防ぎたいのかを伝えてください。

• refresh 後の drift
• import state の誤り
• ステップ間で値が変わること
• destroy 後のクリーンアップ漏れ
• ephemeral データを直接アサートできないこと

これは「完全な例を出して」と頼むより有効です。テストパターンは失敗モード次第で変わるからです。

アサーションを絞り込んで反復する

最初の出力を見たら、まだ残っている不足点を具体的に詰めてください。効果的な追加依頼の例は次のとおりです。

• 「ConfigStateChecks で computed ID の形式をアサートするようにして。」
• 「これを ImportStateKind を使った import テストに書き換えて。」
• 「sweeper を追加して、必要な TestMain の設定も示して。」
• 「echoprovider アプローチを使った ephemeral-resource パターンに変換して。」

こうした反復のほうが、provider-test-patterns guide の出力を長くするだけの依頼より、はるかに質が上がります。