hashicorp / hashicorp/terraform-plugin-testing
Consider adding a `PlanCheck` that verifies a resource is replaced - `ExpectResourceReplacePaths`
- Dominant language
- Go
- Stars
- 68
- Forks
- 22
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 1
Description
### Description
After #63 is merged, we can create new built-in plan checks that may be useful for provider testing.
The plan contains [change information](https://developer.hashicorp.com/terraform/internals/json-format#change-representation) for resources that indicate what object values resulted in a resource being replaced (deleted, then re-created):
```js
{
// ... other change representation fields
// "replace_paths" is an array of arrays representing a set of paths into the
// object value which resulted in the action being "replace". This will be
// omitted if the action is not replace, or if no paths caused the
// replacement (for example, if the resource was tainted). Each path
// consists of one or more steps, each of which will be a number or a
// string.
"replace_paths": [["triggers"]]
}
```
This could be useful for provider developers that need to ensure that certain config changes result in a full delete/create, rather than an update in-place.
We'll need to ensure the [terraform-json](https://github.com/hashicorp/terraform-json/blob/main/plan.go) package is updated to marshal this `replace_paths` attribute
### Other considerations
This implementation should also consider if the testing framework needs to build it's own path system to support functionality like this. The testing code is already leaning on a custom flatmap/HCL reference string syntax, but it can be confusing for developers and required non-HCL-existent syntax for set type attributes since they cannot be indexed.
terraform-plugin-framework's [`path`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/path) package is available, but potentially awkward to link together with the actual JSON paths without also introducing JSON schema handling into the testing code. It would also be a goal to not import the framework code so the testing module remains portable across any existing or future Go-based SDKs.
Contributor guide
Assessment
This issue has not been assessed yet.