I'm trying to reproduce #418 by adding an additional plan step after the apply in test TestAccOpsGenieTeam_complete and expecting an empty plan.
While I can reproduce this case manually using the example given by @fishfacemcgee in #418, simulating it via the TF test framework doesn't show this diff. At least, I expect my change to match the manual TF example.
The test output:
go clean -testcache; TESTARGS="-run TestAccOpsGenieTeam_complete" make testacc
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test $(go list ./... |grep -v 'vendor') -v -run TestAccOpsGenieTeam_complete -timeout 120m
? github.com/opsgenie/terraform-provider-opsgenie [no test files]
=== RUN TestAccOpsGenieTeam_complete
INFO[2024-02-14T13:54:31.648553+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:31.708109+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:31.800555+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:31.812095+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:33.054965+01:00] Could not set requestId.
INFO[2024-02-14T13:54:33.055098+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:33.899992+01:00] Could not set requestId.
INFO[2024-02-14T13:54:33.915478+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:35.101463+01:00] Could not set requestId.
WARN[2024-02-14T13:54:35.504974+01:00] Could not set requestId.
INFO[2024-02-14T13:54:35.505152+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:35.948279+01:00] Could not set requestId.
INFO[2024-02-14T13:54:36.032867+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:36.47367+01:00] Could not set requestId.
INFO[2024-02-14T13:54:36.515232+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:36.605386+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:36.606135+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:37.003919+01:00] Could not set requestId.
INFO[2024-02-14T13:54:37.008582+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:37.559287+01:00] Could not set requestId.
INFO[2024-02-14T13:54:37.6518+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:37.809334+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:37.810066+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:38.684773+01:00] Could not set requestId.
INFO[2024-02-14T13:54:38.687117+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:39.095293+01:00] Could not set requestId.
INFO[2024-02-14T13:54:39.161518+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:39.254155+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:39.255024+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:39.630965+01:00] Could not set requestId.
INFO[2024-02-14T13:54:39.634145+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
WARN[2024-02-14T13:54:40.022433+01:00] Could not set requestId.
INFO[2024-02-14T13:54:40.097841+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:40.260005+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:40.265679+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:40.266263+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:41.77776+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
INFO[2024-02-14T13:54:43.844975+01:00] Client is configured with ApiUrl: api.opsgenie.com, RetryMaxCount: 10
ERRO[2024-02-14T13:54:44.236534+01:00] Error occurred with Status code: 404, Message: No team exists with id [02361d53-a87f-4780-98de-56780d3f611d], Took: 0.004000, RequestId: c30f04fe-fac9-448b-acfd-5f54ff063759
--- PASS: TestAccOpsGenieTeam_complete (12.75s)
PASS
ok github.com/opsgenie/terraform-provider-opsgenie/opsgenie 13.127s
Does the ExpectNonEmptyPlan work correctly, or is there a better way to expect an empty plan?
I'm trying to reproduce #418 by adding an additional
plan
step after theapply
in testTestAccOpsGenieTeam_complete
and expecting an empty plan.While I can reproduce this case manually using the example given by @fishfacemcgee in #418, simulating it via the TF test framework doesn't show this diff. At least, I expect my change to match the manual TF example.
The test output:
Does the
ExpectNonEmptyPlan
work correctly, or is there a better way to expect an empty plan?