Allow providers defined in test files to reference variables and other providers

[liamcervante]

Terraform Version

Terraform v1.6.0

Use Cases

In a regular Terraform file it is possible to write something like this:

provider "vault" {}

data "vault_generic_secret" "aws_creds" {
  path = "some/path/to/secret"
}

provider "aws" {
  access_key_id = data.vault_generic_secret.vault_secrets_automation.data["aws_access_key_id"]
  secret_access_key = data.vault_generic_secret.vault_secrets_automation.data["aws_secret_access_key"]
}

You can't do this for providers defined in Terraform test files currently. In fact, you can't even pass in variables to the provider configurations currently, which is something else we could support.

Attempted Solutions

You can wrap the module you want to test up in another module, define the providers within the module in the same way you would normally, and then test that module. You lose access to validate things about the module under test (like resources and data blocks) with this, but you can still make sure the module actually executes.

Proposal

There are a couple of approaches I can think of. Currently terraform test kind of side loads the provider configuration into the configuration under test during the run block, and then the providers get initialised in the graph along with everything else. We could also just push the data blocks and any additional variables in alongside that. That might lead to clashes with other data blocks, and might allow someone to use a variable that is only defined within a test file but we can add checks for that.

Another idea is to initialise providers outside the Terraform graph, and then pass in the already running providers. The providers would be shared by all the run blocks this way, and that way can do a bit of a load and execute for data blocks and providers in the test file before the run blocks execute.

References

• https://discuss.hashicorp.com/t/how-do-i-pass-provider-information-to-tests/58807

[zanecodes]

Will this also permit referencing resource attributes or module outputs in provider definitions, or only input variables?

My primary use case for terraform test will be running fully self-contained local integration tests for my infrastructure, where provider configuration values (for the module under test) may depend on outputs of a module or resource (from the local mock infrastructure).

For example, say I have a Terraform module that deploys an AWS EC2 instance running an application, and that application requires AWS resources such as S3 buckets, IAM users and roles, an application load balancer, etc. I'd like to be able to test my Terraform without incurring the cost of deploying real AWS resources, and without potentially clobbering any existing infrastructure or deployments in progress in a shared AWS account. I might do this by deploying a Localstack Docker container to my local machine and configuring the AWS provider to point to this container.

To accomplish this, I create the following test files:

tests/integration.tftest.hcl

provider "aws" {
  endpoints {
    iam = run.setup.aws_endpoint
    ec2 = run.setup.aws_endpoint
    s3 = run.setup.aws_endpoint
  }
  region = "sa-east-1"
  access_key = "test"
  secret_key = "test"
  skip_credentials_validation = true
  skip_metadata_api_check = true
  skip_region_validation = true
  skip_requesting_account_id = true
}

run "setup" {
  module {
    source = "./setup"
  }
}

run "deploy" {
}

tests/setup/main.tf

resource "docker_image" "aws" {
  name = "localstack/localstack"
}

resource "docker_container" "aws" {
  name = "aws"
  image = docker_image.aws.image_id

  env = [
    "AWS_REGION=sa-east-1",
    "AWS_ACCESS_KEY_ID=test",
    "AWS_SECRET_ACCESS_KEY=test",
    "SERVICES=iam,ec2,s3"
  ]

  ports {
    internal = 4566
    # For the sake of this example, I don't set `external` here, and allow Docker to select a port automatically instead
  }
}

output "aws_endpoint" {
  value = "http://localhost:${docker_container.aws.ports[0].external}"
}

Would this work?

Or would I instead have to define a variable and reference it in both the provider configuration and the setup module, like this:

tests/integration.tftest.hcl

variables {
  aws_port = 4566
}

provider "aws" {
  endpoints {
    iam = "http://localhost:${aws_port}"
    ec2 = "http://localhost:${aws_port}"
    s3 = "http://localhost:${aws_port}"
  }
  region = "sa-east-1"
  access_key = "test"
  secret_key = "test"
  skip_credentials_validation = true
  skip_metadata_api_check = true
  skip_region_validation = true
  skip_requesting_account_id = true
}

run "setup" {
  module {
    source = "./setup"
  }
}

run "deploy" {
}

tests/setup/main.tf

variable "aws_port" {
  type = number
}

resource "docker_image" "aws" {
  name = "localstack/localstack"
}

resource "docker_container" "aws" {
  name = "aws"
  image = docker_image.aws.image_id

  env = [
    "AWS_REGION=sa-east-1",
    "AWS_ACCESS_KEY_ID=test",
    "AWS_SECRET_ACCESS_KEY=test",
    "SERVICES=iam,ec2,s3"
  ]

  ports {
    internal = 4566
    external = var.aws_port
  }
}

If so, while this would work for this specific example, it would not work in cases where a value needed by a provider is dynamic and cannot be known or set ahead of time.

[liamcervante]

Hi @zanecodes, the original scope of the this ticket was to include variables and data blocks only in the provider configurations.

Currently we can still just initialise the providers at the start of the test file. Your proposal would require us to interleave the run blocks with the providers to work out a run ordering. It's not impossible, but it increases the complexity more than something I think we should do as part of this ticket.

As such, I'll file a separate issue to track this as an extension to the work. I'll need to talk the product team about prioritisation so can't say for sure when it'll be worked on internally.

[zanecodes]

Gotcha, I was mostly just curious about the scope of this ticket and whether the merged pull request would implement said functionality. This feature will already be extremely useful, and I understand the interleaved use case is a bit unusual.

Much appreciated!

[liamcervante]

Call out for testing!

We just released a alpha for v1.7 yesterday.

In the alpha you can reference variables and outputs from run blocks in your provider configurations. This should allow you to create a setup module that uses one provider, load credentials or configuration you need for a second provider from the first provider, and then pass the required data into the second provider.

For example:

# testing/setup/main.tf

data "vault_generic_secret" "aws_credentials" {
  path = "some/path/to/secret"
}

output "aws_access_key_id" {
  sensitive = true
  value = data.vault_generic_secret.aws_credentials.data["AWS_ACCESS_KEY_ID"]
}

output "aws_secret_access_key" {
  sensitive = true
  value = data.vault_generic_secret.aws_credentials.data["AWS_SECRET_ACCESS_KEY"]
}

# tests/main.tftest.hcl

provider "vault" {
  // ... some configuration ...
}

provider "aws" {
  region     = "us-west-2"
  access_key = run.setup.aws_access_key_id
  secret_key = run.setup.aws_secret_access_key
}

run "setup" {
  module {
    source = "./testing/setup"
  }
}

run "test" {
  // ... a normal testing block ...
}

I believe this will address all the use cases mentioned in this ticket. If anyone wants to try it out, please do and file and bugs or enhancement requests you have in new Github tickets. Alternatively jump over to the hashicorp forum and leave your feedback and questions in this post.

Thanks!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.