3. 测试金字塔在 IaC 中的应用：单元测试、集成测试、端到端测试的分层策略与 Terraform 适配

测试金字塔（Test Pyramid）由 Mike Cohn 提出，是指导自动化测试投入比例的经典模型。在基础设施即代码（IaC）领域，该模型需要针对 Terraform 模块的特性进行适配：底层是快速、隔离的单元测试，中层是验证模块间交互的集成测试，顶层是模拟真实环境的端到端（E2E）测试。本章将详细阐述每一层的目标、工具选型及 Terraform 适配策略。

3.1 测试金字塔在 IaC 中的分层模型

传统软件测试金字塔强调“底层多、上层少”，IaC 测试同样遵循这一原则，但测试对象从代码函数变为基础设施资源定义与状态。下图展示了适配 Terraform 的测试金字塔分层结构：

3.2 单元测试：验证模块内部逻辑

单元测试是金字塔的基石，在 Terraform 模块测试中，单元测试的目标是不创建真实基础设施，仅验证模块的输入校验、输出推导、条件逻辑和本地计算。其核心工具是 terraform validate 和 terraform fmt，以及第三方工具 terratest 的模拟模式。

3.2.1 单元测试覆盖范围

3.2.2 单元测试工具与示例

推荐使用 Terratest 的 terraform.InitAndPlan 函数结合 assert 包进行单元测试。以下示例验证模块输入变量校验是否生效：

// unit_test.go
package test

import (
    "testing"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/stretchr/testify/assert"
)

func TestModuleInputValidation(t *testing.T) {
    t.Parallel()

    // 定义违反校验规则的输入
    invalidOptions := map[string]interface{}{
        "instance_type": "t2.micro", // 假设模块要求最小为 t3.medium
        "environment":   "invalid-env",
    }

    terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
        TerraformDir: "../examples/simple",
        Vars:         invalidOptions,
    })

    // 期望 plan 失败
    _, err := terraform.InitAndPlan(t, terraformOptions)
    assert.Error(t, err)
    assert.Contains(t, err.Error(), "Invalid instance_type")
}

3.3 集成测试：验证模块间交互

集成测试位于金字塔中层，目标是验证 Terraform 模块与外部依赖（如网络、数据库、IAM 角色）之间的交互是否正确。这一层会创建真实的基础设施资源，但通常限制在单个云服务或小型资源组内。

3.3.1 集成测试核心关注点

• 资源依赖顺序：验证 depends_on 和隐式依赖是否按预期解析。
• 数据源读取：验证 data 块能否正确查询现有资源。
• 模块输出传递：验证一个模块的输出能否被另一个模块正确消费。
• Provider 配置：验证不同 provider 别名和区域配置是否生效。
• 远程状态交互：验证模块能否从远程状态存储读取数据。

3.3.2 集成测试工具与示例

Terratest 的 terraform.InitAndApply 和 terraform.Output 是集成测试的主力。以下示例验证 VPC 模块与子网模块的输出传递：

// integration_test.go
package test

import (
    "testing"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/stretchr/testify/assert"
)

func TestVpcSubnetIntegration(t *testing.T) {
    t.Parallel()

    terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
        TerraformDir: "../examples/vpc-with-subnets",
    })

    defer terraform.Destroy(t, terraformOptions)

    // 执行 apply
    terraform.InitAndApply(t, terraformOptions)

    // 获取模块输出
    vpcId := terraform.Output(t, terraformOptions, "vpc_id")
    subnetIds := terraform.OutputList(t, terraformOptions, "subnet_ids")

    // 断言：子网数量与预期一致
    assert.Equal(t, 3, len(subnetIds))

    // 断言：子网属于该 VPC（通过 AWS SDK 验证）
    // 此处可调用 AWS SDK 进行额外验证
    t.Logf("VPC ID: %s, Subnet Count: %d", vpcId, len(subnetIds))
}

3.4 端到端测试：验证完整业务场景

端到端测试位于金字塔顶端，模拟最接近生产环境的完整工作流。在 Terraform 模块测试中，E2E 测试会部署完整的服务目录模板（包括网络、计算、存储、安全组等），并验证业务功能是否正常。

3.4.1 E2E 测试典型场景

3.4.2 E2E 测试工具与策略

E2E 测试通常结合 Terratest 与云 SDK（如 AWS SDK、Azure SDK）进行。关键策略包括：

• 阶段化部署：分步 apply，每步验证后再继续，便于定位失败点。
• 健康检查：使用 retry 机制等待资源就绪（如 HTTP 200 响应）。
• 清理保障：使用 terraform destroy 和云 SDK 的强制清理作为双重保险。
• 并行隔离：每个测试用例使用独立的 Terraform 工作目录和状态文件。

// e2e_test.go
package test

import (
    "testing"
    "time"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/gruntwork-io/terratest/modules/http-helper"
)

func TestWebAppEndToEnd(t *testing.T) {
    t.Parallel()

    terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
        TerraformDir: "../examples/web-app",
    })

    defer terraform.Destroy(t, terraformOptions)

    // 阶段 1：部署网络层
    terraform.InitAndApply(t, terraformOptions.WithTarget("module.vpc"))

    // 阶段 2：部署计算层
    terraform.Apply(t, terraformOptions.WithTarget("module.ec2"))

    // 阶段 3：部署应用层并获取 URL
    terraform.Apply(t, terraformOptions)
    appUrl := terraform.Output(t, terraformOptions, "app_url")

    // 验证应用可访问
    http_helper.HttpGetWithRetry(t, appUrl, nil, 200, "Hello World", 30, 5*time.Second)
}

3.5 三层测试的投入比例与适配建议

下表总结了 IaC 测试金字塔各层的核心特征及 Terraform 适配要点：

3.6 测试分层策略的常见误区

• 误区一：所有测试都用 E2E。 导致测试套件运行数小时，反馈周期过长。应优先用单元测试覆盖逻辑。
• 误区二：单元测试不验证输出。 仅验证 terraform validate 通过是不够的，必须断言输出值和本地变量。
• 误区三：集成测试不销毁资源。 导致云费用持续累积。始终使用 defer terraform.Destroy 或 CI 清理钩子。
• 误区四：忽略测试隔离。 多个测试共享同一状态文件会导致竞态条件。每个测试用例应使用独立的 terraform.Workspace 或目录。