provider-test-patterns

provider-test-patterns 技能概覽

provider-test-patterns 是一個 Terraform provider 驗收測試技能，適合使用 terraform-plugin-testing 搭配 Plugin Framework 的團隊。它能幫你以比通用提示更少的試錯來撰寫、審查與除錯 provider 測試，特別是在你需要選對 TestCase、TestStep、state 檢查、plan 檢查、匯入驗證，或 sweeper 設定時。

最佳適用情境與要完成的工作

當你的真實需求是：「我需要一個可靠的 provider resource 驗收測試模式，而且想知道這個情境該用哪一種測試結構」時，就該使用 provider-test-patterns 技能。它最適合 provider 的後端開發工作，因為難點不只在語法，而是在選對 assertion 策略與生命週期覆蓋範圍。

最擅長涵蓋的內容

provider-test-patterns 技能在你需要以下指引時最有幫助：

• 跨 plan、apply、refresh、destroy 的測試生命週期流程
• TestCase 與 TestStep 的結構
• ConfigStateChecks、plancheck 與 CompareValue
• 使用 ImportStateKind 的匯入測試
• sweeper 與清理安全性
• 基本、更新、disappears、驗證與 regression 等情境模式
• 使用 echoprovider 模式的 ephemeral resource 測試

什麼情況下很值得安裝

如果你想要的是直接對應 Terraform provider 驗收測試的、帶有明確立場的模式建議，那就安裝 provider-test-patterns。對於已經在 Plugin Framework 上工作的後端開發團隊來說，它比通用提示更合適，尤其當主要風險是漏掉必要檢查、用錯 assertion 類型，或把測試結構寫得難以維護時。

如何使用 provider-test-patterns 技能

安裝並載入到目前脈絡

先依照你的 skill manager 使用 repository 安裝流程，然後先打開 SKILL.md。上游技能本身沒有定義自己的安裝指令，所以實際上的 provider-test-patterns install 步驟，就是透過你所用 agent 的 skills 工作流程把技能加入，接著閱讀技能檔與支援參考資料。

先從測試形狀開始，不要先從程式碼開始

最好的 provider-test-patterns usage 流程，是在要求產生程式碼之前先描述情境。請說明：

• resource 類型與生命週期階段
• 這是 basic、update、import、disappears、validation，還是 regression 覆蓋
• state 或 plan 需要驗證什麼
• 是否需要透過 sweeper 做清理
• 這個案例是否涉及 ephemeral resource

這樣技能才有足夠結構去判斷要用一般 config 檢查、statecheck、plancheck，或跨步驟比較。

先讀這些檔案

為了快速上手，請依照這個順序閱讀：

1. SKILL.md：主模式集合與生命週期指引
2. references/checks.md：statecheck、plancheck、known values 與 comparers
3. references/ephemeral.md：如果 resource 是 ephemeral，或使用 echoprovider
4. references/sweepers.md：如果你擔心有資源殘留

有效的提示詞範本

針對 provider-test-patterns，好的提示應該包含 resource、失敗模式與你想要的 assertion 風格。例如：

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 驗收測試設計的，對 provider-test-patterns for Backend Development 特別有用，因為你需要在 state、plan 與 cleanup 行為上得到可靠覆蓋。

我需要先熟悉 terraform-plugin-testing 嗎？

不需要，但這個技能預設你是在那個生態系中工作。若你是新手，它仍然有幫助，因為它能減少你在測試結構上的猜測；但你還是應該回頭對照引用文件與你自己的 provider 測試慣例，確認細節。

它跟一般提示有什麼不同？

一般提示可能產出一個看起來合理的 test file，但 provider-test-patterns 在 assertion 選擇很重要時更有價值。它會幫你根據測試真正目的，判斷該用 ConfigStateChecks、plan check、destroy check、import state 驗證，還是 sweeper 模式。

什麼情況下不該用它？

不要拿它來做通用單元測試、無關的 Go 測試，或只想快速確認語法的問題。若你不是在做 Terraform provider 驗收測試，它也不太適合，因為這些模式與限制都是針對那個工作流程設計的。

如何改善 provider-test-patterns 技能

一開始就提供缺少的測試事實

要讓 provider-test-patterns 的結果更好，最有效的方法是先提供會改變測試設計的最小必要資訊：

• resource 名稱與 provider 套件
• resource 是建立、更新、匯入，還是刪除
• 必須檢查的精確屬性
• 值是靜態、computed、sensitive，還是跨步驟
• 測試是否必須涵蓋清理或漏清恢復

說明你想避免的失敗

如果你說明可能出錯的地方，技能就能選到更好的 assertions。例如，告訴它你是在防範：

• refresh 後出現 drift
• import state 錯誤
• 步驟之間的值變動
• destroy 後沒有正確清理
• ephemeral data 無法直接做 assertion

這比要求一個「完整範例」更有用，因為測試模式其實取決於失敗模式。

用更精準的 assertion 持續迭代

拿到第一版輸出後，再用你仍然看到的缺口去收斂需求。好的後續追問包括：

• 「把 ConfigStateChecks 改成驗證 computed ID 格式。」
• 「改寫成使用 ImportStateKind 的匯入測試。」
• 「加上 sweeper，並示範必要的 TestMain 設定。」
• 「改成用 echoprovider 方法的 ephemeral-resource 模式。」

這種迭代方式，比要求更長的版本，更能改善 provider-test-patterns guide 的輸出。