Testing input variables in experimental terraform test feature

Terraform
1

I’m trying to use the experimental test command to test the input variable of a module.

Given the module

module "rds-aurora" {
  source  = "terraform-aws-modules/rds-aurora/aws"
  for_each = {
    for cluster in var.clusters : cluster.name => cluster
  }
  etc..  
  etc..
  allowed_cidr_blocks   = concat(
    var.allowed_cidr_blocks,
    each.value.custom_cluster_allowed_cidr_blocks
  )
}

how can i test the allowed_cidr_blocks input variable of the terraform-aws-modules/rds-aurora/aws module? is it possible?
in the test_assertions resource I can access only to the output variables.

Something like that:

module "main" {
  source = "../.."
  
  allowed_cidr_blocks = ["1.1.1.0/24"]

  clusters = [{
    name: "test",
    custom_cluster_allowed_cidr_blocks = ["1.1.0.0/24"]
}

locals {
  expected_allowed_cidrs_blocks = ["1.1.1.0/24", "1.1.0.0/24"]
}

resource "test_assertions" "allowed_cidr_blocks" {
  component = "allowed_cidr_blocks"

  equal "cidr_block" {
    description = "should set the correct cidr"
    got         = module.main["test"].INPUTS.allowed_cidr_blocks
    want        = local.expected_allowed_cidrs_blocks
  }
}

Thanks!

2

Hi @manuelmazzuola,

The current incarnation of the test experiment is focused exclusively on “closed box” integration testing, so it’s designed for testing whether the module has the expected effect on the remote system rather than testing details of how the module itself is implemented.

It’s likely that a future incarnation of this experiment will have some unit testing capabilities too, but the Terraform team is currently focused on other work so I can’t say with certainty what exactly that will look like.

With that said: the specific example you shared seems a bit confusing to me because you seem to have written a test that would (assuming Terraform had a way to let you write it) always fail: the allowed_cidr_blocks value you passed as input doesn’t match the local.expected_allowed_cidrs_blocks value that you seem to be comparing it to. I’m not sure I understand why it would be valuable to directly test the input variables because those are part of the test scenario rather than part of the module under test, so any failures there would presumably be describing problems with the test code rather than problems with the code you were trying to test. :thinking: Can you say some more about your underlying goal here? I’d love to pass your use-case on to our product manager to help inform future work on this feature.