Terraform 模块测试框架

要解决的问题

手写 Terraform 模块测试时，最常见的问题是"看起来能用"和"实际可用"之间的差距。terraform plan 输出一个 plan 文件，里面包含将要创建的资源和属性，但没有人保证 plan 里的内容就是你想要的。比如你期望 instance_type 是 t3.micro，但模块里可能写了默认值 t3.small；你期望安全组规则按特定顺序追加，但 diff 可能和预期完全不同。

另一个问题：验证模块时需要真正把基础设施跑起来。只做静态检查，无法覆盖 depends_on、count、for_each 这类动态行为，也没法验证资源属性之间的联动。手工到云厂商控制台创建临时环境又太慢，做完之后忘了清理还会产生意外费用。

工作方式

这个技能围绕两个测试路径展开：

• Terratest Go 库：用 Go 写测试代码，调用 Terraform 的 CLI 或云厂商 SDK 来执行 plan 和 apply，再对结果做断言。适合需要精细控制验证逻辑、或验证资源间联动关系的场景。
• Terraform 原生测试框架：使用 terraform test 命令和 .tftest.hcl 文件，在声明式测试中对比 plan 输出与期望结果。适合快速验证模块暴露的变量和默认值是否符合预期。

核心步骤包括：

1. 在临时环境中执行 terraform apply，把模块真正部署出来；
2. 对资源属性进行断言，确认字段值、标签、依赖关系符合预期；
3. 通过 terraform destroy 或 test 框架的自动清理机制回收临时资源。

Terratest 路径把清理逻辑写在测试代码里，defer 注册销毁步骤，即使断言失败也会执行；原生框架的 test 命令在每次测试结束后自动销毁创建的资源，不需要手动管理。

适用边界与注意点

这个框架是给模块作者或平台团队做回归测试用的，不是给生产环境做实时校验的工具。测试需要在有真实云凭据的环境里跑，因为要真正创建资源，凭据权限至少需要覆盖测试用到的所有资源类型。

Terratest 路径要求你熟悉 Go 测试的写法，t.Run、t.Fatal 这类概念需要理解；原生框架虽然学习成本低，但 check 块能表达的断言类型有限，复杂逻辑仍要回到代码里。两个路径的测试速度都取决于云 API 的响应时间，不适用于 CI 中毫秒级反馈的需求。

Terratest 测试如果断言失败，清理逻辑依赖 defer 正确注册；如果 apply 本身就失败了，可能没有资源可清理，但也要注意部分资源创建后仍然产生费用的情况。原生框架的 test 命令在 terraform destroy 失败时也会留下残留资源，需要定期检查。