【Terraform】terraform test は plan モードなら $0 で書ける話

はじめに

IaC にもテストを入れたいと思いつつ、「テスト＝実際にリソースを作って確認」だと思っていて、課金が怖くてずっと後回しにしていました。

でも Terraform 標準の terraform test は、command = plan を指定すれば実リソースを作らずに設定を検証できます。実リソースを作らないので、課金リスクをかなり抑えてテストが書けました。

先に結論：terraform test は既定だと apply（実際に作る）ですが、各テストに command = plan を書けばプランの計算だけで評価され、リソースは作られません。

「ほぼ $0」と書いているのは、plan でも provider の認証や data source 参照で AWS の API 呼び出しは発生するためです。通常は大きな課金要因ではありませんが、「絶対に 0 円」と言い切らずにおきます。

環境

• Terraform（ネイティブの terraform test / .tftest.hcl）
• 対象は AWS 向けの構成（Lambda・S3・API Gateway・CloudFront など）
• リージョン: ap-northeast-1（東京）

きっかけ：直したものが、また戻らないように守りたい

直前に「Lambda のランタイムが古くなる」対応をして、現行の nodejs22.x に上げたばかりでした。こういう修正は、あとで誰か（未来の自分含む）がうっかり戻すと困ります。

そこで「この構成ではランタイムに nodejs22.x を使い続ける」をテストで固定することにしました。これが最初の1本です。

# tests/serverless.tftest.hcl
run "lambda_uses_supported_runtime" {
  command = plan                      # ← 実リソースを作らない

  module {
    source = "./modules/lambda"       # ← モジュール単体を検証
  }
  variables {
    project       = "aws-study"
    function_name = "hello"
  }

  assert {
    condition     = aws_lambda_function.this.runtime == "nodejs22.x"
    error_message = "Lambda runtime は、この構成の標準である nodejs22.x を使う"
  }
}

terraform test で実行すると、これが通ります。何も作らずに「ランタイムは想定どおりか？」だけを確認できました。

どのランタイムが現行/非推奨かは時期で変わります。実際に固定する版は、公開時点の AWS Lambda の対応ランタイム表（参考リンク）で確認してください。

なお、module { source = "./modules/lambda" } の相対パスは、テストを実行する構成ディレクトリ（terraform test を叩く場所）を基準に解決されます。私はそこを基準に確認しました。

plan と apply の違い（ここが安く済む肝）

公式ドキュメントによると、run ブロックの command は**省略すると既定は apply**で、実際にリソースを作って検証します。command = plan を指定すると、プランの計算結果に対してアサートするので、リソースは作られません。

command = apply （既定）… 実際に作る → 課金・後片付けが要る
command = plan        … 作らない   → ほぼ $0

plan テストで向いていること / apply が要ること

全部 plan で済むわけではないので、最初に切り分けておくと迷いません。

plan テストで向いていること

• 変数の validation が効くこと
• IAM ポリシーや公開設定など、設定値の確認
• ランタイム・タグ・命名規則の固定
• モジュールの入力と出力の確認

apply テストが必要になりやすいこと

• 実際の AWS サービス連携
• Lambda の実行結果
• API Gateway 経由の疎通
• CloudFront 配信後の挙動

「設定が意図どおりか」を確かめたいだけなら plan、「実際に動くか」を見たいなら apply、という住み分けです。

いろいろな検証を plan で書く

モジュール内部を検証する（module {}）

「S3 は公開を全ブロックしているか」。

run "s3_blocks_all_public_access" {
  command = plan
  module { source = "./modules/static_site" }
  variables {
    project = "aws-study"
    suffix  = "test"
  }
  assert {
    condition = (
      aws_s3_bucket_public_access_block.this.block_public_acls &&
      aws_s3_bucket_public_access_block.this.block_public_policy &&
      aws_s3_bucket_public_access_block.this.ignore_public_acls &&
      aws_s3_bucket_public_access_block.this.restrict_public_buckets
    )
    error_message = "S3 バケットは公開を全ブロックすべき"
  }
}

「不正な入力はちゃんと弾かれる」を検証する（expect_failures）

正しく動くことだけでなく、「ダメな入力をちゃんと拒否する」のもテストできます。SSH 元 IP に全開放（0.0.0.0/0）を渡したら、variable の validation で弾かれてほしい。

run "rejects_wide_open_my_ip" {
  command = plan
  variables {
    my_ip = "0.0.0.0/0"
  }
  expect_failures = [
    var.my_ip,         # ← この変数の検証が失敗することを“期待”する
  ]
}

expect_failures は「ここは失敗するのが正しい」という宣言です。逆に、正しい値（203.0.113.10/32）なら通ることも、別の run で確認しています。

こうして、ランタイム・S3 公開ブロック・API Gateway の構成・CloudFront の既定ルート・入力バリデーションなどを plan のまま 8 本書いて、全部 pass しました。

ハマったところ：依存を足したら init し直し

途中で、テストに新しい module { source = "..." } を追加したら、「初期化されていない」と怒られました。テストが参照するモジュールやプロバイダは、実行前に取得されている必要があります。新しいモジュールや provider の依存を追加・変更したら、terraform init を再実行して依存を取得・更新してから terraform test を回す、で解決しました。

学び

• terraform test は既定が apply。command = plan を書けば実リソースを作らず、ほぼ $0。
• 「設定値が意図どおりか」は plan、「実際に動くか」は apply、と住み分ける。
• module {} でモジュール単体を、assert で値を、expect_failures で「不正入力を弾くこと」を検証できる。
• 依存（モジュール/provider）を足したら terraform init を忘れずに。
• 「戻したくない修正」は、テストで固定しておくと安心。

おわりに

「テスト＝お金がかかる」という思い込みで避けていたのが、plan モードを知って一気に書けるようになりました😊 まずは1本、「この値はこうあってほしい」を plan で固定するところから始めると、とっつきやすいと思います🙌

参考

• Terraform 公式: Tests（.tftest.hcl / run / command / expect_failures）
  https://developer.hashicorp.com/terraform/language/tests
• Terraform 公式: terraform test コマンド
  https://developer.hashicorp.com/terraform/cli/commands/test
• AWS公式: Lambda ランタイム（対応・非推奨スケジュール。公開時点で要確認）
  https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html