Implement provider resource and data source acceptance tests with the terraform-plugin-testing module. These tests are designed to execute Terraform commands against real Terraform configurations, simulating practitioner experiences with creating, refreshing, updating, and deleting infrastructure.
This page only describes requirements of using the testing module with a framework provider. Refer to the testing module documentation for additional information on all available functionality in tests.
The testing module must know how to reference your provider code before Terraform commands and configurations can succeed. This is achieved by pointing the testing module at a provider server which wraps your provider.
Use one of the resource.TestCase type ProtoV6ProviderFactories field for protocol version 6 or ProtoV5ProviderFactories field for protocol version 5. It is only necessary to test with the single protocol version matching the production provider server, typically defined in the main.go file of the provider codebase.
Use the providerserver.NewProtocol6WithError helper function to implement the provider server in the ProtoV6ProviderFactories field.
resource.Test(t, resource.TestCase{
ProtoV6ProviderFactories: map[string]func() (tfprotov6.ProviderServer, error) {
// newProvider is an example function that returns a provider.Provider
"examplecloud": providerserver.NewProtocol6WithError(newProvider()),
},
Steps: []resource.TestStep{/* ... */},
})
Use the providerserver.NewProtocol5WithError helper function to implement the provider server in the ProtoV5ProviderFactories field.
resource.Test(t, resource.TestCase{
ProtoV5ProviderFactories: map[string]func() (tfprotov5.ProviderServer, error) {
// newProvider is an example function that returns a provider.Provider
"examplecloud": providerserver.NewProtocol5WithError(newProvider()),
},
Steps: []resource.TestStep{/* ... */},
})
Tip
terraform-plugin-testing version 1.5.0 and later no longer require managed resources and data resources to implement the id attribute.
In SDKv2, resources and data sources automatically included an implicit, root level id attribute. In the framework, the id attribute is not implicitly added.
When testing resources and data sources without the id attribute, the acceptance testing framework will return errors such as:
testing_new_config.go:111: no "id" found in attributes
testing_new.go:53: no "id" found in attributes
To avoid this, add a root level id attribute to resource and data source schemas. Ensure the attribute value is appropriately written to state. Conventionally, id is a computed attribute that contains the identifier for the resource.
For example, in the Schema method implementation of a datasource.DataSource or resource.Resource:
func (r *ThingResource) Schema(ctx context.Context, req resource.SchemaRequest, resp *resource.SchemaResponse) {
resp.Schema = schema.Schema{
// ... potentially other schema configuration ...
Attributes: map[string]schema.Attribute{
// ... potentially other schema attributes ...
"id": schema.StringAttribute{
Computed: true,
},
},
}
}
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4