Hello @berahtlv and thank you for your issue!

I took a quick look and it works the same way for me. We handled variable defaults here, but didn't take into account variable type.

It looks like a bug indeed so let us get back to you after the core team discussion.

Looking at the example from the original issue, I'd note that as currently written that test ought to also fail for a different reason, because:

• var.root_disk is declared as being of an object type with four attributes
• the assert block's condition is comparing it to a value of type object({size = number}), without the other three attributes.
• The == can only return true if the two operands have exactly the same type.

If the test harness were correctly setting var.root_disk to have the same value it would have when used inside the module -- which I assume is the intent -- then in order to pass this test would need to change to one of the two following forms:

run "root_disk_var" {
  command = plan

  variables {
    root_disk = {
      size = 60
    }
  }

  assert {
    # This variation would fail immediately if any new
    # attributes were added to the variable's type
    # constraint in future.
    condition = var.root_disk == {
      size       = 60
      type       = "gp3"
      iops       = tonumber(null)
      throughput = tonumber(null)
    }
    error_message = "Value is incorrect"
  }
}

run "root_disk_var" {
  command = plan

  variables {
    root_disk = {
      size = 60
    }
  }

  # This variation tolerates the addition of new attributes
  # without failing, by testing each attribute separately.
  assert {
    condition = (var.root_disk.size == 60)
    error_message = "Size is incorrect"
  }
  assert {
    condition = (var.root_disk.type == "gp3")
    error_message = "Type is incorrect"
  }
  assert {
    condition = (var.root_disk.iops == tonumber(null))
    error_message = "IOps is incorrect"
  }
  assert {
    condition = (var.root_disk.throughput == tonumber(null))
    error_message = "Throughput is incorrect"
  }
}

It seems like at the moment the bug reported by this issue is masking this problem. I'm mentioning it here only in the hope that it's helpful to someone working on this issue in future, since there is more than one way for the given example to fail and so it starting to fail does not necessarily mean that the bug is fixed.

Hey @cam72cam, may I take a look at this?

Hey @AdosH1 thank you for volunteering! Let me assign you, but before opening a PR, please describe your approach here so we can sync on the chosen implementation path.

@ollevche In terms of the solution, I think the configVariables should contain a Default cty value of that object, and attempt to set each field that hasn't been set earlier. Would that be a reasonable start on this issue?

I don't have a strong opinion for ApparentlyMart's assertation methodology, but leaning towards the exact object matching given its for the test command (which we have full control over inputs)
I've been confused however, why the test command (with plan) behaves quite differently from the tests for plan command

Hey @AdosH1! Sorry for delay with reply from my side.

I think to resolve this particular issue (type defaults are not being applied to test variables), we need to extend parseAndApplyDefaultValues function to also handle TypeDefaults from config variables.

Object comparison is out of the scope of this particular bug in my opinion.

Thanks ollevche, I will take a look in the coming week 🙏