variable "environment" has a validation block that only allows dev, stage or prod. A module author wants a test that passes precisely because the value qa is rejected, and fails if the validation is ever removed. Which run block achieves this?
Select an answer to reveal the explanation.
![To Create an exciting colorful infographic that explains the concepts in the question: Question: variable "environment" has a validation block that only allows dev, stage or prod. A module author wants a test that passes precisely because the value qa is rejected, and fails if the validation is ever removed. Which run block achieves this? Correct Answer: A run block with command = plan, variables { environment = "qa" }, and expectfailures = [var.environment] Put EVERY visible label in double quotes. No people. No A/B/C/D letters. In one of the four corners put a little "Navy Duck".](/media/hashicorp/terraform-pro-002/TERRAFORM-PRO-002-e1-q253.webp)
Short Explanation
You want the test to cheer when the bouncer turns qa away at the door. expect_failures pointed at var.environment does exactly that. The trap is an assert: validation stops Terraform before the assert ever runs.
Full Explanation
The expect_failures attribute lists checkable objects, such as input variables, resources, data sources, check blocks and outputs, whose custom conditions are expected to fail. The run passes only if those objects report a failure, so removing the validation later turns a passing test into a failing one, which is the regression signal the author wants. Pairing it with command = plan is the documented recommendation, because expectations apply to the operation the run performs and an apply-mode run that fails during planning fails overall. An assert block cannot express this: validation failures halt Terraform before assertions are evaluated, so the run errors on the validation instead of evaluating the assert. Listing an output in expect_failures expects the output's own precondition to fail; here the failing object is the variable, and with command = apply the run would fail during plan regardless. There is no mechanism that compares an assert against a validation's error_message text, and values supplied in the test file outrank -var on the command line. Exam caveat: expected failures cover user-defined custom conditions only; a type mismatch, such as a number passed to a string variable, still fails the test. Operational check: run terraform test, confirm the run passes, then temporarily delete the validation block and confirm the same run now fails.