ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/internal/moduletest/provider_test.go

156 lines
4.8 KiB
Go
Raw Normal View History

internal/moduletest: Experimental module testing helpers As part of ongoing research into Terraform testing we'd like to use an experimental feature to validate our current understanding that expressing tests as part of the Terraform language, as opposed to in some other language run alongside, is a good and viable way to write practical module integration tests. This initial experimental incarnation of that idea is implemented as a provider, just because that's an easier extension point for research purposes than a first-class language feature would be. Whether this would ultimately emerge as a provider similar to this or as custom language constructs will be a matter for future research, if this first experiment confirms that tests written in the Terraform language are the best direction to take. The previous incarnation of this experiment was an externally-developed provider apparentlymart/testing, listed on the Terraform Registry. That helped with showing that there are some useful tests that we can write in the Terraform language, but integrating such a provider into Terraform will allow us to make use of it in the also-experimental "terraform test" command, which will follow in subsequent commits, to see how this might fit into a development workflow.
2021-02-05 01:08:51 +01:00
package moduletest
import (
"testing"
"github.com/google/go-cmp/cmp"
Move providers/ to internal/providers/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 19:40:40 +02:00
"github.com/hashicorp/terraform/internal/providers"
internal/moduletest: Experimental module testing helpers As part of ongoing research into Terraform testing we'd like to use an experimental feature to validate our current understanding that expressing tests as part of the Terraform language, as opposed to in some other language run alongside, is a good and viable way to write practical module integration tests. This initial experimental incarnation of that idea is implemented as a provider, just because that's an easier extension point for research purposes than a first-class language feature would be. Whether this would ultimately emerge as a provider similar to this or as custom language constructs will be a matter for future research, if this first experiment confirms that tests written in the Terraform language are the best direction to take. The previous incarnation of this experiment was an externally-developed provider apparentlymart/testing, listed on the Terraform Registry. That helped with showing that there are some useful tests that we can write in the Terraform language, but integrating such a provider into Terraform will allow us to make use of it in the also-experimental "terraform test" command, which will follow in subsequent commits, to see how this might fit into a development workflow.
2021-02-05 01:08:51 +01:00
"github.com/zclconf/go-cty-debug/ctydebug"
"github.com/zclconf/go-cty/cty"
)
func TestProvider(t *testing.T) {
assertionConfig := cty.ObjectVal(map[string]cty.Value{
"component": cty.StringVal("spline_reticulator"),
"equal": cty.MapVal(map[string]cty.Value{
"match": cty.ObjectVal(map[string]cty.Value{
"description": cty.StringVal("this should match"),
"got": cty.StringVal("a"),
"want": cty.StringVal("a"),
}),
"unmatch": cty.ObjectVal(map[string]cty.Value{
"description": cty.StringVal("this should not match"),
"got": cty.StringVal("a"),
"want": cty.StringVal("b"),
}),
}),
"check": cty.MapVal(map[string]cty.Value{
"pass": cty.ObjectVal(map[string]cty.Value{
"description": cty.StringVal("this should pass"),
"condition": cty.True,
}),
"fail": cty.ObjectVal(map[string]cty.Value{
"description": cty.StringVal("this should fail"),
"condition": cty.False,
}),
}),
})
// The provider code expects to receive an object that was decoded from
// HCL using the schema, so to make sure we're testing a more realistic
// situation here we'll require the config to conform to the schema. If
// this fails, it's a bug in the configuration definition above rather
// than in the provider itself.
for _, err := range assertionConfig.Type().TestConformance(testAssertionsSchema.Block.ImpliedType()) {
t.Error(err)
}
p := NewProvider()
command: Experimental "terraform test" command This is just a prototype to gather some feedback in our ongoing research on integration testing of Terraform modules. The hope is that by having a command integrated into Terraform itself it'll be easier for interested module authors to give it a try, and also easier for us to iterate quickly based on feedback without having to coordinate across multiple codebases. Everything about this is subject to change even in future patch releases. Since it's a CLI command rather than a configuration language feature it's not using the language experiments mechanism, but generates a warning similar to the one language experiments generate in order to be clear that backward compatibility is not guaranteed.
2021-02-09 01:03:15 +01:00
configureResp := p.ConfigureProvider(providers.ConfigureProviderRequest{
internal/moduletest: Experimental module testing helpers As part of ongoing research into Terraform testing we'd like to use an experimental feature to validate our current understanding that expressing tests as part of the Terraform language, as opposed to in some other language run alongside, is a good and viable way to write practical module integration tests. This initial experimental incarnation of that idea is implemented as a provider, just because that's an easier extension point for research purposes than a first-class language feature would be. Whether this would ultimately emerge as a provider similar to this or as custom language constructs will be a matter for future research, if this first experiment confirms that tests written in the Terraform language are the best direction to take. The previous incarnation of this experiment was an externally-developed provider apparentlymart/testing, listed on the Terraform Registry. That helped with showing that there are some useful tests that we can write in the Terraform language, but integrating such a provider into Terraform will allow us to make use of it in the also-experimental "terraform test" command, which will follow in subsequent commits, to see how this might fit into a development workflow.
2021-02-05 01:08:51 +01:00
Config: cty.EmptyObjectVal,
})
if got, want := len(configureResp.Diagnostics), 1; got != want {
t.Fatalf("got %d Configure diagnostics, but want %d", got, want)
}
if got, want := configureResp.Diagnostics[0].Description().Summary, "The test provider is experimental"; got != want {
t.Fatalf("wrong diagnostic message\ngot: %s\nwant: %s", got, want)
}
command: Experimental "terraform test" command This is just a prototype to gather some feedback in our ongoing research on integration testing of Terraform modules. The hope is that by having a command integrated into Terraform itself it'll be easier for interested module authors to give it a try, and also easier for us to iterate quickly based on feedback without having to coordinate across multiple codebases. Everything about this is subject to change even in future patch releases. Since it's a CLI command rather than a configuration language feature it's not using the language experiments mechanism, but generates a warning similar to the one language experiments generate in order to be clear that backward compatibility is not guaranteed.
2021-02-09 01:03:15 +01:00
validateResp := p.ValidateResourceConfig(providers.ValidateResourceConfigRequest{
internal/moduletest: Experimental module testing helpers As part of ongoing research into Terraform testing we'd like to use an experimental feature to validate our current understanding that expressing tests as part of the Terraform language, as opposed to in some other language run alongside, is a good and viable way to write practical module integration tests. This initial experimental incarnation of that idea is implemented as a provider, just because that's an easier extension point for research purposes than a first-class language feature would be. Whether this would ultimately emerge as a provider similar to this or as custom language constructs will be a matter for future research, if this first experiment confirms that tests written in the Terraform language are the best direction to take. The previous incarnation of this experiment was an externally-developed provider apparentlymart/testing, listed on the Terraform Registry. That helped with showing that there are some useful tests that we can write in the Terraform language, but integrating such a provider into Terraform will allow us to make use of it in the also-experimental "terraform test" command, which will follow in subsequent commits, to see how this might fit into a development workflow.
2021-02-05 01:08:51 +01:00
TypeName: "test_assertions",
Config: assertionConfig,
})
if got, want := len(validateResp.Diagnostics), 0; got != want {
t.Fatalf("got %d ValidateResourceTypeConfig diagnostics, but want %d", got, want)
}
planResp := p.PlanResourceChange(providers.PlanResourceChangeRequest{
TypeName: "test_assertions",
Config: assertionConfig,
PriorState: cty.NullVal(assertionConfig.Type()),
ProposedNewState: assertionConfig,
})
if got, want := len(planResp.Diagnostics), 0; got != want {
t.Fatalf("got %d PlanResourceChange diagnostics, but want %d", got, want)
}
planned := planResp.PlannedState
if got, want := planned, assertionConfig; !want.RawEquals(got) {
t.Fatalf("wrong planned new value\n%s", ctydebug.DiffValues(want, got))
}
gotComponents := p.TestResults()
wantComponents := map[string]*Component{
"spline_reticulator": {
Assertions: map[string]*Assertion{
"pass": {
Outcome: Pending,
Description: "this should pass",
},
"fail": {
Outcome: Pending,
Description: "this should fail",
},
"match": {
Outcome: Pending,
Description: "this should match",
},
"unmatch": {
Outcome: Pending,
Description: "this should not match",
},
},
},
}
if diff := cmp.Diff(wantComponents, gotComponents); diff != "" {
t.Fatalf("wrong test results after planning\n%s", diff)
}
applyResp := p.ApplyResourceChange(providers.ApplyResourceChangeRequest{
TypeName: "test_assertions",
Config: assertionConfig,
PriorState: cty.NullVal(assertionConfig.Type()),
PlannedState: planned,
})
if got, want := len(applyResp.Diagnostics), 0; got != want {
t.Fatalf("got %d ApplyResourceChange diagnostics, but want %d", got, want)
}
final := applyResp.NewState
if got, want := final, assertionConfig; !want.RawEquals(got) {
t.Fatalf("wrong new value\n%s", ctydebug.DiffValues(want, got))
}
gotComponents = p.TestResults()
wantComponents = map[string]*Component{
"spline_reticulator": {
Assertions: map[string]*Assertion{
"pass": {
Outcome: Passed,
Description: "this should pass",
Message: "condition passed",
},
"fail": {
Outcome: Failed,
Description: "this should fail",
Message: "condition failed",
},
"match": {
Outcome: Passed,
Description: "this should match",
Message: "correct value\n got: \"a\"\n",
},
"unmatch": {
Outcome: Failed,
Description: "this should not match",
Message: "wrong value\n got: \"a\"\n want: \"b\"\n",
},
},
},
}
if diff := cmp.Diff(wantComponents, gotComponents); diff != "" {
t.Fatalf("wrong test results after applying\n%s", diff)
}
}