Currently we generate acceptance tests from example files. These typically include:
a step for provisioning the resource (“Does this config apply without error?”)
a step that verifies that the resource can be imported and the state of the imported resource matches the state of the resource when it was originally provisioned (“Is the import logic for this resource able to fully import resources as if they were originally created by Terraform?”).
The import step is only tested in a context where there are provider-default values available; the tests are run in an environment where GOOGLE_PROJECT, GOOGLE_REGION etc environment variables are set. This means that we miss resources where the import process isn’t written in a way where the project (etc) is derived from the user-provided id string. This is a blindspot of our testing that could be improved.
What kind of contribution is this issue about?
Other (specify in details)
Details
Currently we generate acceptance tests from example files. These typically include:
The import step is only tested in a context where there are provider-default values available; the tests are run in an environment where GOOGLE_PROJECT, GOOGLE_REGION etc environment variables are set. This means that we miss resources where the import process isn’t written in a way where the project (etc) is derived from the user-provided id string. This is a blindspot of our testing that could be improved.
For example this acceptance test, TestAccPubsubTopic_pubsubTopicBasicExample, could be updated like this:
References
No response