hashicorp / hashicorp/terraform-plugin-testing

Consider adding a `PlanCheck` that verifies a resource is replaced - `ExpectResourceReplacePaths`

Open
#107 5 comments 2 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.