2015-11-05 15:47:08 +01:00
package command
import (
2017-08-28 21:01:11 +02:00
"os"
2015-11-05 15:47:08 +01:00
"strings"
"testing"
2016-02-08 23:04:24 +01:00
"github.com/mitchellh/cli"
2018-10-13 18:33:18 +02:00
"github.com/zclconf/go-cty/cty"
"github.com/hashicorp/terraform/configs/configschema"
2018-10-14 16:59:15 +02:00
"github.com/hashicorp/terraform/terraform"
2015-11-05 15:47:08 +01:00
)
2017-07-05 18:32:29 +02:00
func setupTest ( fixturepath string , args ... string ) ( * cli . MockUi , int ) {
2015-11-05 15:47:08 +01:00
ui := new ( cli . MockUi )
2018-10-13 18:33:18 +02:00
p := testProvider ( )
p . GetSchemaReturn = & terraform . ProviderSchema {
ResourceTypes : map [ string ] * configschema . Block {
"test_instance" : {
Attributes : map [ string ] * configschema . Attribute {
"ami" : { Type : cty . String , Optional : true } ,
} ,
BlockTypes : map [ string ] * configschema . NestedBlock {
"network_interface" : {
Nesting : configschema . NestingList ,
Block : configschema . Block {
Attributes : map [ string ] * configschema . Attribute {
"device_index" : { Type : cty . String , Optional : true } ,
"description" : { Type : cty . String , Optional : true } ,
} ,
} ,
} ,
} ,
} ,
} ,
}
2015-11-05 15:47:08 +01:00
c := & ValidateCommand {
Meta : Meta {
2018-10-13 18:33:18 +02:00
testingOverrides : metaOverridesForProvider ( p ) ,
2017-07-05 18:32:29 +02:00
Ui : ui ,
2015-11-05 15:47:08 +01:00
} ,
}
2017-07-05 18:32:29 +02:00
args = append ( args , testFixturePath ( fixturepath ) )
2015-11-05 15:47:08 +01:00
code := c . Run ( args )
return ui , code
}
2017-07-05 18:32:29 +02:00
2015-11-05 15:47:08 +01:00
func TestValidateCommand ( t * testing . T ) {
if ui , code := setupTest ( "validate-valid" ) ; code != 0 {
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
t . Fatalf ( "unexpected non-successful exit code %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
2015-11-05 15:47:08 +01:00
}
}
2017-08-28 21:01:11 +02:00
func TestValidateCommandWithTfvarsFile ( t * testing . T ) {
// Create a temporary working directory that is empty because this test
// requires scanning the current working directory by validate command.
td := tempDir ( t )
2020-10-07 18:48:25 +02:00
testCopyDir ( t , testFixturePath ( "validate-valid/with-tfvars-file" ) , td )
2017-08-28 21:01:11 +02:00
defer os . RemoveAll ( td )
defer testChdir ( t , td ) ( )
ui := new ( cli . MockUi )
c := & ValidateCommand {
Meta : Meta {
testingOverrides : metaOverridesForProvider ( testProvider ( ) ) ,
Ui : ui ,
} ,
}
args := [ ] string { }
if code := c . Run ( args ) ; code != 0 {
t . Fatalf ( "bad %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
}
2015-11-05 15:47:08 +01:00
func TestValidateFailingCommand ( t * testing . T ) {
if ui , code := setupTest ( "validate-invalid" ) ; code != 1 {
t . Fatalf ( "Should have failed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
}
func TestValidateFailingCommandMissingQuote ( t * testing . T ) {
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
// FIXME: Re-enable once we've updated core for new data structures
t . Skip ( "test temporarily disabled until deep validate supports new config structures" )
2015-11-05 15:47:08 +01:00
ui , code := setupTest ( "validate-invalid/missing_quote" )
if code != 1 {
t . Fatalf ( "Should have failed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
if ! strings . HasSuffix ( strings . TrimSpace ( ui . ErrorWriter . String ( ) ) , "IDENT test" ) {
t . Fatalf ( "Should have failed: %d\n\n'%s'" , code , ui . ErrorWriter . String ( ) )
}
}
func TestValidateFailingCommandMissingVariable ( t * testing . T ) {
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
// FIXME: Re-enable once we've updated core for new data structures
t . Skip ( "test temporarily disabled until deep validate supports new config structures" )
2015-11-05 15:47:08 +01:00
ui , code := setupTest ( "validate-invalid/missing_var" )
if code != 1 {
t . Fatalf ( "Should have failed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
2017-11-22 00:08:00 +01:00
if ! strings . HasSuffix ( strings . TrimSpace ( ui . ErrorWriter . String ( ) ) , "config: unknown variable referenced: 'description'; define it with a 'variable' block" ) {
2015-11-05 15:47:08 +01:00
t . Fatalf ( "Should have failed: %d\n\n'%s'" , code , ui . ErrorWriter . String ( ) )
}
}
func TestSameProviderMutipleTimesShouldFail ( t * testing . T ) {
ui , code := setupTest ( "validate-invalid/multiple_providers" )
if code != 1 {
t . Fatalf ( "Should have failed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
wantError := "Error: Duplicate provider configuration"
if ! strings . Contains ( ui . ErrorWriter . String ( ) , wantError ) {
t . Fatalf ( "Missing error string %q\n\n'%s'" , wantError , ui . ErrorWriter . String ( ) )
2015-11-05 15:47:08 +01:00
}
}
func TestSameModuleMultipleTimesShouldFail ( t * testing . T ) {
ui , code := setupTest ( "validate-invalid/multiple_modules" )
if code != 1 {
t . Fatalf ( "Should have failed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
wantError := "Error: Duplicate module call"
if ! strings . Contains ( ui . ErrorWriter . String ( ) , wantError ) {
t . Fatalf ( "Missing error string %q\n\n'%s'" , wantError , ui . ErrorWriter . String ( ) )
2015-11-05 15:47:08 +01:00
}
}
func TestSameResourceMultipleTimesShouldFail ( t * testing . T ) {
ui , code := setupTest ( "validate-invalid/multiple_resources" )
if code != 1 {
t . Fatalf ( "Should have failed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
wantError := ` Error: Duplicate resource "aws_instance" configuration `
if ! strings . Contains ( ui . ErrorWriter . String ( ) , wantError ) {
t . Fatalf ( "Missing error string %q\n\n'%s'" , wantError , ui . ErrorWriter . String ( ) )
2015-11-05 15:47:08 +01:00
}
}
func TestOutputWithoutValueShouldFail ( t * testing . T ) {
ui , code := setupTest ( "validate-invalid/outputs" )
if code != 1 {
t . Fatalf ( "Should have failed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
2018-11-24 21:46:49 +01:00
wantError := ` The argument "value" is required, but no definition was found. `
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
if ! strings . Contains ( ui . ErrorWriter . String ( ) , wantError ) {
t . Fatalf ( "Missing error string %q\n\n'%s'" , wantError , ui . ErrorWriter . String ( ) )
}
2018-11-24 21:46:49 +01:00
wantError = ` An argument named "values" is not expected here. Did you mean "value"? `
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
if ! strings . Contains ( ui . ErrorWriter . String ( ) , wantError ) {
t . Fatalf ( "Missing error string %q\n\n'%s'" , wantError , ui . ErrorWriter . String ( ) )
2015-11-05 15:47:08 +01:00
}
}
func TestModuleWithIncorrectNameShouldFail ( t * testing . T ) {
ui , code := setupTest ( "validate-invalid/incorrectmodulename" )
if code != 1 {
t . Fatalf ( "Should have failed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
wantError := ` Error: Invalid module instance name `
if ! strings . Contains ( ui . ErrorWriter . String ( ) , wantError ) {
t . Fatalf ( "Missing error string %q\n\n'%s'" , wantError , ui . ErrorWriter . String ( ) )
2015-11-05 15:47:08 +01:00
}
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
wantError = ` Error: Variables not allowed `
if ! strings . Contains ( ui . ErrorWriter . String ( ) , wantError ) {
t . Fatalf ( "Missing error string %q\n\n'%s'" , wantError , ui . ErrorWriter . String ( ) )
2015-11-05 15:47:08 +01:00
}
}
func TestWronglyUsedInterpolationShouldFail ( t * testing . T ) {
ui , code := setupTest ( "validate-invalid/interpolation" )
if code != 1 {
t . Fatalf ( "Should have failed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
wantError := ` Error: Variables not allowed `
if ! strings . Contains ( ui . ErrorWriter . String ( ) , wantError ) {
t . Fatalf ( "Missing error string %q\n\n'%s'" , wantError , ui . ErrorWriter . String ( ) )
2015-11-05 15:47:08 +01:00
}
2019-06-18 23:58:48 +02:00
wantError = ` A single static variable reference is required `
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
if ! strings . Contains ( ui . ErrorWriter . String ( ) , wantError ) {
t . Fatalf ( "Missing error string %q\n\n'%s'" , wantError , ui . ErrorWriter . String ( ) )
2015-11-05 15:47:08 +01:00
}
}
2017-07-05 18:32:29 +02:00
func TestMissingDefinedVar ( t * testing . T ) {
ui , code := setupTest ( "validate-invalid/missing_defined_var" )
command: beginnings of new config loader in "terraform validate"
As part of some light reorganization of our commands, this new
implementation no longer does validation of variables and will thus avoid
the need to spin up a fully-valid context. Instead, its focus is on
validating the configuration itself, regardless of any variables, state,
etc.
This change anticipates us later adding a -validate-only flag to
"terraform plan" which will then take over the related use-case of
checking if a particular execution of Terraform is valid, _including_ the
state, variables, etc.
Although leaving variables out of validate feels pretty arbitrary today
while all of the variable sources are local anyway, we have plans to
allow per-workspace variables to be stored in the backend in future and
at that point it will no longer be possible to fully validate variables
without accessing the backend. The "terraform plan" command explicitly
requires access to the backend, while "terraform validate" is now
explicitly for local-only validation of a single module.
In a future commit this will be extended to do basic type checking of
the configuration based on provider schemas, etc.
2018-03-01 02:14:05 +01:00
// This is allowed because validate tests only that variables are referenced
// correctly, not that they all have defined values.
2017-07-05 18:32:29 +02:00
if code != 0 {
t . Fatalf ( "Should have passed: %d\n\n%s" , code , ui . ErrorWriter . String ( ) )
}
}
