如何在Terraform验收测试中测试terraform import功能？

导入测试步骤的实际执行逻辑 #

你担心的「本地state已存在资源导入会报错」的情况不会出现，Terraform Provider验收测试框架的每个TestStep都使用独立的临时工作目录和隔离的state文件，不会复用前面步骤的本地state：

• 第一步执行tf plan & tf apply的核心作用是在云服务商侧生成真实的资源实例，同时记录该实例的ID、所有属性的预期值
• 到第二步导入步骤时，框架会生成仅包含对应资源声明的空配置，初始化空白state，再用第一步生成的资源ID执行terraform import操作
• 开启ImportStateVerify: true后，框架会自动把导入生成的state属性和第一步apply得到的预期属性做全量对比，完全一致才会判定测试通过，以此验证资源的导入逻辑正确，不存在漏读属性、属性值转换错误的问题

你提到的示例测试代码就是这个典型的验收测试结构：

func TestAccExampleThing_basic(t *testing.T) {
  /* ... 其他已有的验收测试逻辑 ... */

  resource.ParallelTest(t, resource.TestCase{
    /* ... 已有的TestCase配置 ... */
    Steps: []resource.TestStep{
      /* ... 已有的apply测试步骤 ... */
      {
        ResourceName:      "example_thing.test",
        ImportState:       true,
        ImportStateVerify: true,
      },
    },
  })
}

多次导入步骤的作用 #

AWS Provider测试用例中两次导入的设计，是为了覆盖资源全生命周期的导入兼容性：

• 第2步的导入：验证资源刚创建完成的初始状态可以正常导入，导入结果符合预期
• 第3步执行update操作：修改资源配置属性，执行apply后云上资源属性对应更新，同时记录更新后的属性预期值
• 第4步的导入：验证修改后的资源状态依然可以正常导入，导入后的属性和更新后的预期值完全匹配，避免出现资源修改部分属性后，导入逻辑无法正确读取新属性、属性转换出错的问题

内容的提问来源于stack exchange，提问作者Alex Kuzmin