run-acceptance-tests

run-acceptance-tests 技能概览

这个技能能做什么

run-acceptance-tests 技能帮助你正确运行 Terraform provider 的 acceptance tests，尤其是那些以 TestAcc 开头命名的测试。它面向的是 run-acceptance-tests 的 Acceptance Testing 工作流：重点不只是“把测试跑起来”，而是要在合适的环境中运行、读懂失败原因，并判断何时需要额外的 provider 专属配置。

适合谁使用

如果你正在开发 Terraform provider，并且需要一份实用的 run-acceptance-tests 指南，用来做本地验证、CI 排障，或者复现偶发失败结果，那么这个技能就很合适。它最适用于你已经明确知道要跑哪个 acceptance test，但又不想靠猜 flags 或环境变量来碰运气的场景。

它的不同之处

这个技能对关键执行顺序有明确取舍：先从有针对性的 go test -run=... 开始，只有在第一次运行信息不够时，才逐步加上 -count=1、-v、TF_LOG=debug，以及 workspace 持久化。这让 run-acceptance-tests 技能比通用提示更有价值，因为它内置的是一条诊断阶梯，而不是让你自己临场发挥。

如何使用 run-acceptance-tests 技能

安装该技能

使用以下命令安装 run-acceptance-tests 技能：
npx skills add hashicorp/agent-skills --skill run-acceptance-tests

如果你是在评估 Terraform provider 工作流里的 run-acceptance-tests 安装效果，先确认你的环境可以运行 Go tests，并且在需要时能够安全地配置 provider 凭据。这个技能默认的是 acceptance-testing 场景，不是一个独立的演示项目。

提供一个精确的测试目标

最好的输入是一个具体的 TestAcc 名称，而不是“帮我检查一下 provider 测试”这种模糊请求。比如，你可以这样提问：“运行 TestAccFeatureHappyPath，并诊断缺失的 env vars。” 只有当测试名称、provider 和预期行为都明确时，这个技能才能发挥最佳效果。

先从正确的文件和信号入手

先查看 SKILL.md，然后检查仓库里的 README.md、AGENTS.md、metadata.json，以及任何存在的 rules/、resources/、references/ 或 scripts/ 目录。在这个仓库里，主要指导信息集中在 SKILL.md，所以相比大型技能，文件树排查的重要性没那么高，但确认是否存在隐藏的辅助文件仍然很有帮助。

按执行与排障阶梯推进

正常运行时，先使用 TF_ACC=1 go test -run=TestAccFeatureHappyPath，并且一开始保持输出非 verbose。若测试失败，先加 -count=1 避免缓存结果，再加 -v，然后加 TF_LOG=debug，最后才考虑使用 TF_ACC_WORKING_DIR_PERSIST=1 来检查各步骤之间的 Terraform state。这种分阶段的工作流，正是 run-acceptance-tests 使用模式的核心。

run-acceptance-tests 技能常见问题

这只适用于 Terraform provider acceptance tests 吗？

是的。run-acceptance-tests 技能的范围就是 Terraform provider 的 acceptance testing，尤其是使用 TestAcc 命名约定的 Go tests。它不面向单元测试、通用 Go test 套件，或其他无关的基础设施检查。

如果测试需要额外的环境变量怎么办？

这是预期之内的。这个技能明确假设某些 provider 需要额外的环境变量，并会引导你从测试输出里找出缺失的变量，再以安全方式配置它们。如果缺少凭据或 endpoint，把它当作 run-acceptance-tests 指南的一部分，而不是这个技能本身有问题。

我需要它来替代普通 prompt 吗？

当你需要的是可重复的流程，而不是一次性的回答时，就该使用这个技能。普通 prompt 可能只会告诉你“去跑测试”；而 run-acceptance-tests 技能会告诉你在第一次尝试失败，或者测试虽然通过但仍需验证时，应该使用哪些 flags、环境变量和升级步骤。

对新手友好吗？

如果你已经会运行 Go 命令，并且理解基本的环境变量，那它是友好的。这个技能通过从一个聚焦的命令和清晰的排障升级路径开始，减少了新手的试错成本，但它仍然要求你能识别 provider 专属凭据、Terraform 行为，以及测试命名约定。

如何改进 run-acceptance-tests 技能

提供更强的测试上下文

最有用的输入包括准确的测试名、provider 包，以及你想复现的症状。只说“运行 acceptance tests”太宽泛；而“运行 internal/provider 包里的 TestAccResourceBasic，并排查缺失的 TF_LOG 线索”则能给技能足够上下文，让它更快选对路径。

分享失败细节，而不只是失败状态

如果第一次运行失败，请带上完整的测试输出、缺失变量提示，以及在加了 -count=1 或 -v 之后结果是否发生变化。run-acceptance-tests 技能会随着你提供真实失败形态而变得更有效，因为 provider acceptance tests 常常会因不同原因失败：认证问题、远程 API 尚未就绪、state 漂移，或者测试本身不稳定。

按正确顺序使用调试选项

先请求最小必要的升级，只有在证据要求时再继续加码。对于 run-acceptance-tests 的用法，这通常意味着先从一个聚焦的 TestAcc 名称开始，只有在知道自己需要看什么之后，才追加 verbose 输出、debug 日志或 workspace 持久化。

调整测试本身，而不只是命令

如果你要确认一个通过的测试是否真的有意义，不要只重复同一条命令；改动一个检查或一个步骤后再重新运行。这样能让 run-acceptance-tests 技能在 Acceptance Testing 里更有价值，因为它能帮助你区分真正的通过和假阴性，并随着时间推移不断收紧测试信号。