🎍皆さん、あけましておめでとうございます。🎍@masa-asa です。
先日まで開催していましたアドベントカレンダーはお読みになりましたでしょうか。
花王株式会社という IT 系でない企業でも沢山の方々が多様なスキルを活かして活躍しており、個性豊かな
記事を発信してくださっていますので、ぜひご一読ください。

@masa-asa としても、引き続き投稿を続けて行く予定ですので、2026 年もよろしくお願いいたします🙇

今回の記事は Terraform のテスト実行時間を短縮するには？がテーマです。

`terraform test` が長すぎる...

Google Cloud のシステムを IaC で構築していたある日、比較的大きめの改修を行った後に CI を行っていました。
なんか CI が異常に長いなと思っていると、なんと terraform test の実行に 10 分以上もかかっていました。
さすがにこのままだとまずいぞと思い原因を探ることに。

`run` ブロックを多用

一番長いテストコードを見てみます。

run "empty_location" {
  command = plan

  variables {
    env      = var.env
    location = ""
  }
  expect_failures = [var.location]
}

run "invalid_memory1" {
  command = plan

  variables {
    memory = "512.5Mi"
  }
  expect_failures = [var.memory]
}

run "invalid_crun_be_log_level1" {
  command = plan

  variables {
    crun_be_log_level = "DUMMY"
  }
  expect_failures = [var.crun_be_log_level]
}

・
・
・

このように 1 つの変数に対する 1 つのテストケースに対して、1 つの run ブロックが使われていました。その数 100 個近く！長さにして 1000 行以上にも上るテストコードです。
さらにこれほどまではいかなくても数百行ほどのテストコードが他にも複数モジュール分ある...
なんとかしなければ、となりテスト時間の圧縮にとりかかりました。

`run` ブロックをできるだけまとめる

run ブロックが多すぎるのでまとめることが一番大きな効果を生みます。

run "validation_base_config_consolidated" {
  command = plan


  # Test multiple invalid base configurations
  variables {
    env          = ""       # Invalid: empty
    location     = ""       # Invalid: empty
    project_name = "TESTPJ" # Invalid: uppercase
  }

  expect_failures = [
    var.env,
    var.location,
    var.project_name
  ]
}

上記は run ブロックをまとめた例です。この例では env、location、project_name の変数に対するバリデーションを 1 つのブロックにまとめています。
このようにまとめられたブロックでエラーが発生した場合には以下のように検知できます。location で問題が発生した場合を想定します。

cloud_run_test.tftest.hcl... in progress
  run "valid_all_services"... pass
  run "validation_base_config_consolidated"... fail
╷
│ Error: Missing expected failure
│ 
│   on cloud_run_test.tftest.hcl line 137, in run "validation_base_config_consolidated":
│  137:     var.location,
│ 
│ The checkable object, var.location, was expected to report an error but did not.
╵
  run "validation_network_consolidated"... skip
  run "validation_resource_consolidated"... skip
  run "validation_service_accounts_consolidated"... skip
cloud_run_test.tftest.hcl... tearing down
cloud_run_test.tftest.hcl... fail

Failure! 1 passed, 1 failed, 3 skipped.

どの変数でエラーが出ているかは把握することができるので、まとめた場合でも失敗している変数を追うことは可能です。

`mock_provider` を活用する

terraform test が動作する際に利用するプロバイダーをモックに置き換えることで時間の短縮が見込まれます。
例えば Google Cloud についてのモックプロバイダーを作成する場合は以下のように記述できます。

mock_provider "google" {
}

最終的に...

全体的にテストコードの run ブロックをまとめ、一番 run ブロックが多かったテストも 100 個近くから 10 数個に削減し、プロバイダーをモックに置き換えました。

結果、テスト実行時間を 1/4 〜 1/5 に短縮することができました！
この時点で、テストに時間がかかっていたときよりもモジュールが増えていることを考慮すると大きい効果が出ている事がわかります。

まとめ

今回のまとめは以下の 2 点です。

run ブロックをまとめて数を少なくするとテスト時間を短くできる
モックプロバイダーを使うことで、テスト時間の短縮が期待できる

改めて 2026 年も頑張っていきますので、これからもよろしくお願いします！