provider-test-patterns

provider-test-patterns 技能概览

provider-test-patterns 是一个面向使用 terraform-plugin-testing 和 Plugin Framework 的团队的 Terraform provider 接受测试技能。它能帮助你更少试错地编写、审查和调试 provider 测试，尤其适合你需要正确的 TestCase、TestStep、状态检查、计划检查、导入验证或 sweeper 配置时，而不是只靠一个通用提示词碰运气。

最佳适用场景与要完成的任务

当你的真实需求是：“我需要一个可靠的 provider 资源接受测试模式，并且想知道哪种测试结构适合这个场景”时，就该使用 provider-test-patterns 技能。它最适合 provider 的后端开发工作，因为这里真正难的往往不只是语法，而是要选对断言策略和生命周期覆盖方式。

它最擅长覆盖的内容

当你需要以下方面的指导时，provider-test-patterns 技能最强：

• 覆盖 plan、apply、refresh 和 destroy 的测试生命周期流程
• TestCase 和 TestStep 的结构
• ConfigStateChecks、plancheck 和 CompareValue
• 使用 ImportStateKind 做导入测试
• sweeper 与清理安全性
• basic、update、disappears、validation 和 regression 等场景模式
• 使用 echoprovider 模式的临时资源测试

什么时候它是很合适的安装选择

如果你想要一套带明确观点、并且能直接映射到 Terraform provider 接受测试的模式，provider-test-patterns 值得安装，尤其适合已经在 Plugin Framework 中工作的后端开发团队。相比通用提示词，它更适合用在主要风险是漏掉必要检查、用了错误的断言类型，或者把测试结构写得难以维护的场景。

如何使用 provider-test-patterns 技能

安装并在上下文中加载

先按你的 skill manager 的仓库安装流程添加该技能，然后优先打开 SKILL.md。上游技能本身没有定义专用安装命令，因此实际的 provider-test-patterns install 步骤，就是通过你的 agent skills 工作流把它加入，然后再阅读该技能及其配套参考文档。

先从测试形状入手，而不是直接上代码

最佳的 provider-test-patterns usage 工作方式，是先描述场景，再请求代码。你应该说明：

• 资源类型和生命周期阶段
• 这是 basic、update、import、disappears、validation 还是 regression 覆盖
• 需要在 state 或 plan 中断言什么
• 是否需要通过 sweepers 做清理
• 是否涉及临时资源

这样技能才有足够结构去判断应该用普通 config 检查、statecheck、plancheck，还是跨步骤比较。

先阅读这些文件

为了快速上手，请按以下顺序阅读：

1. SKILL.md：主模式集合和生命周期指导
2. references/checks.md：statecheck、plancheck、已知值和比较器
3. references/ephemeral.md：如果资源是临时资源，或使用 echoprovider
4. references/sweepers.md：如果你担心资源泄漏

高质量提示词模板

适合 provider-test-patterns 的提示词，应该同时包含资源、失败模式和期望的断言方式。例如：

为 example_widget 的 update 行为编写一个接受测试。我需要一个 TestStep 序列，验证 name 会变化、旧值会在 refresh 前保留，并且最终 state 与新配置一致。如果 CompareValue 更合适，就用它。

这比直接说“写一个测试”更有效，因为它给了技能一个明确的决策目标，而不只是一个主题。

provider-test-patterns 技能常见问题

provider-test-patterns 只适合 Terraform provider 工程师吗？

基本上是的。它是为 Terraform provider 接受测试设计的，在 provider-test-patterns for Backend Development 这类场景里最有价值，因为你需要围绕 state、plan 和清理行为获得可靠覆盖。

我需要已经熟悉 terraform-plugin-testing 吗？

不需要，但这个技能默认你是在该生态里工作。即使你是新手，它也有帮助，因为它能减少你在测试结构上的猜测；不过你还是应该结合引用的文档以及你自己 provider 现有的测试约定来核对细节。

它和普通提示词有什么区别？

普通提示词也许能生成一个看起来合理的测试文件，但当断言类型的选择很关键时，provider-test-patterns 会更有用。它能帮助你根据测试的真实目的，判断该用 ConfigStateChecks、plan 检查、destroy 检查、导入 state 验证，还是 sweeper 模式。

什么时候不该用它？

不要把它用于通用单元测试、无关的 Go 测试，或者只问语法、不要逻辑的快速问题。它也不适合你根本没有在做 Terraform provider 接受测试的情况，因为这些模式和约束就是围绕这套工作流设计的。

如何改进 provider-test-patterns 技能

一开始就给出缺失的测试事实

想让 provider-test-patterns 的结果更好，最有效的方法是提供会影响测试设计的最小必要信息：

• 资源名称和 provider 包
• 资源是创建、更新、导入还是销毁
• 必须检查的精确属性
• 值是静态的、计算得出的、敏感的，还是需要跨步骤比较的
• 测试是否必须覆盖清理或泄漏恢复

说明你要防止的失败模式

如果你说清楚可能出错的地方，技能就能选出更好的断言方式。例如，告诉它你是在防范：

• refresh 之后出现 drift
• 错误的导入 state
• 步骤之间的值变化
• destroy 清理缺失
• 临时数据无法直接断言

这比要求一个“完整示例”更有用，因为测试模式取决于失败模式。

通过收紧断言来迭代

拿到第一版输出后，用你仍然看到的具体缺口继续收敛需求。好的后续追问包括：

• “让 ConfigStateChecks 断言计算出的 ID 格式。”
• “把这个改成使用 ImportStateKind 的导入测试。”
• “加上 sweeper，并展示所需的 TestMain 设置。”
• “用 echoprovider 方法把它改成临时资源模式。”

这种迭代方式，能比单纯要求更长的版本更有效地提升 provider-test-patterns guide 的输出质量。