-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExpectError is ignored for test case where destroy action expected to have error #609
Comments
I am hitting a similar issue. I want to test a case where the attempted deletion of a resource with dependencies should fail. The apply does fail with the expected error, but then the test itself errors out due to dangling resources:
Are there any updates on this? Is there a way around this that anyone knows of? |
It's not a solution but a workaround. Try adding a step at the end which successfully creates the resources and it should work.
|
Hmm. . . @AniketKariya that didn't work for me. |
I have a use case where destroys should only succeed/be allowed if the resource specifies https://github.com/hashicorp/terraform-plugin-sdk/blob/main/helper/resource/testing_new.go#L24 |
Hasn't been merged yet but I have a PR to handle this in a way similar to |
Hi folks 👋 The testing framework generally expects tests to always destroy successfully at the end of a Does setting up the testing using a resource.TestCase{
// ... other fields ...
Steps: []resource.TestStep{
{
Config: "# config that successfully creates resource, but requires forced destruction",
// ... potentially other fields ...
},
{
Config: "# config that should unsuccessfully destroy resource, potentially same as above Config",
Destroy: true,
ExpectError: regexp.MustCompile(/*...*/),
// ... potentially other fields ...
},
{
Config: "# config that successfully applies forced destruction settings to resource so it can be destroyed by TestCase"
// ... potentially other fields ...
},
},
} It should also be possible to set |
@bflad that makes perfect sense, nonetheless it's perfectly normal for a provider to fail when deleting resources, intentionally, for any number of reasons. I spent some time looking into this (existing providers) and I came to the conclusion that people just don't have tests for such cases, which is not ideal.
So let's flip this back to you - are you saying that you will not add/allow functionality which can handle (expected) failed deletes? I'm all for simplicity but in my case, being able to validate this behavior is desirable. |
Hi @matthewcummings and @IronSavior - something I think we need to make sure we check: have you tried to have a
Are you saying that you tested that, and found that in case of error, |
Hi @detro yes, I have tried that. It doesn't work, when the post test destroy runs, if there's an error, there's no current way to handle it, see https://github.com/hashicorp/terraform-plugin-sdk/blob/main/helper/resource/testing_new.go#L32 |
@detro any update on this? |
@detro checking again. . . any updates here? |
I have similar issue. I want to let provider user to explicitly set I have traced sdk source code, just like @matthewcummings found. Calling Although I have acknowledged that there are some resource will still left on tfstate, I want to execute sweepers to clean up the resource after acceptance test. terraform-plugin-sdk/helper/resource/testing_new.go Lines 21 to 34 in ed85ac4
|
Hey there, any update on this? |
This is an old thread - but there is a way to make it work:
Destroy will be called twice. |
Maybe I'm doing this wrong?
SDK version
Relevant provider source code
Debug Output
Test output:
Expected Behavior
Test should pass because the delete operation is expected to fail
Actual Behavior
Test fails because the resource is not destroyed.
Steps to Reproduce
Create an apply/destroy test case where the destroy is guaranteed to fail.
References
#347 - Except their problem was during resource creation.
The text was updated successfully, but these errors were encountered: