Upgrading to Terraform v1.6

Terraform v1.6 is a minor release in the stable Terraform v1.0 series.

Terraform v1.6 honors the Terraform v1.0 Compatibility Promises, but there are some behavior changes outside of those promises that may affect a small number of users. Specifically, the following updates may require additional upgrade steps:

• End of experimental period for terraform test

See the full changelog for more details. If you encounter any problems during upgrading which are not covered this guide, please start a new topic in the Terraform community forum to discuss it.

Terraform Test

The previous experimental terraform test command has been deprecated and replaced with a fully supported and finalized terraform test command.

There are substantial differences between the previous experimental approach and the finalized approach:

• The builtin test provider, terraform.io/builtin/test, has been removed and a dedicated syntax introduced for testing files.
• A new .tftest.hcl file extension has been introduced for testing files, allowing a change into the directory structure and test file layout.
• Test assertions and conditions execute with extended scope and access to the configuration under test.

The major differences are discussed here, for more information consult the CLI and Language documentation.

Directory structure

Previously, test files would be placed within their own subdirectories underneath the tests directory from the configuration directory. The following example contains three test files using the experimental framework:

main.tf
outputs.tf
providers.tf
variables.tf
tests/
  defaults/
    test_defaults.tf
  maximums/
    test_maximums.tf
  minimums/
    test_minimums.tf

With the new directory structure, tests are defined using the new .tftest.hcl file extension and do not need to be embedded within subdirectories. To help with organization, test files can, optionally, be embedded within a test directory. The name for this test directory defaults to tests, but can be overridden with the -test-directory flag.

The following examples are both valid directory structures for test files in the updated framework:

main.tf
outputs.tf
providers.tf
variables.tf
defaults.tftest.hcl
maximums.tftest.hcl
minimums.tftest.hcl

main.tf
outputs.tf
providers.tf
variables.tf
tests/
  defaults.tftest.hcl
  maximums.tftest.hcl
  minimums.tftest.hcl

Test structure and assertions

Previously, a test file would contain a module call and a collection of resources from the builtin test provider:

# tests/defaults/test_defaults.tf

terraform{
  required_providers {
    test = {
      source = "terraform.io/builtin/test"
    }
  }
}

module "main" {
  source = "../.."
}

resource "test_assertions" "api_url" {
  component = "api_url"

  equal "scheme" {
    description = "default scheme is https"
    got         = module.main.scheme
    want        = "https"
  }
  check "port_number" {
    description = "default port number is 8080"
    condition   = can(regex(":8080$", module.main.authority))
  }
}

With the new framework each test file is made up of a series of run blocks. Each run block represents a single terraform plan or a terraform apply operation executed against the main configuration. Assertions from within these run blocks can access outputs, variables, resources, and local values from the main configuration directly.

# tests/defaults.tftest.hcl

run "test_defaults" {
  assert {
    condition     = output.scheme == "https"
    error_message = "default scheme should be https"
  }

  assert {
    condition     = can(regex(":8080", output.authority))
    error_message = "default port number should be 8080"
  }
}

The above examples demonstrates the differences in layout, scope and access between the two approaches. In the experimental framework, access is granted as if the configuration was being called like a normal module call. In the released framework, assertions execute as if they are custom conditions defined within the main configuration directly.

The run block also applies or plans the main configuration by default, there is no need for the specific module call seen in the experimental framework.