Open paultyng opened 4 years ago
Interested in that.
One of such cases is testing if ReadFunc
in resource behaves properly when the resource does not exist anymore (basically to test if it conforms with recommended approach).
If it was possible to create and inject a state I could:
ID
(and additional mandatory fields if needed)refresh
or apply
I was able to achieve similar functionality with data sources currently by doing the following:
func Provider() terraform.ResourceProvider
Config
template This way the test should cover data sources added in future.
Hi folks 👋
With the introduction of the terraform-plugin-testing module (migration guide), we are transferring feature requests relating to the helper/resource
"testing framework" in the terraform-plugin-sdk repository over to the new terraform-plugin-testing repository.
Thanks again for this feature request.
This is related to #73, but not quite the same thing. Potentially without major refactoring, something like ConfigDirectory
from #72 might also be sufficient for this use case (e.g. where an existing state file could be in that sort of setup).
Use-cases
For some tests, its hard to get the TF state and upstream API in the proper state to reproduce observed issues (ie reading when deleting upstream without first creating then deleting through SDK, or some issues with provider upgrades or things that may not be possible in the API but possible in the UI, etc.). It may be useful (or in some cases just more expedient) to explicitly set the starting state for a resource in a
TestCase
prior to executing it.