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

[austinvalle]

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 for resources that indicate what object values resulted in a resource being replaced (deleted, then re-created):

{
  // ... 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 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 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.

[bflad]

Now seeing the replace_paths implementation, we could consider follow the abstraction it already provides such as accepting a []string of path steps so we do not need to reinvent another path system. The plan JSON has been stable for awhile now, so I'm not sure if we necessarily need to abstract it. That sort of plan JSON change would introduce a large burden on the Terraform ecosystem so it wouldn't be done unless there were some major benefits to doing so.

The main consideration to a []string implementation would then be seeing how set element paths are represented, such as a set nested attribute or set nested block where an underlying attribute is what is triggering the replacement. I think that would help determine whether that type of solution would be okay.

[bflad]

This should be enabled in the next version of terraform-json: hashicorp/terraform-json#117

Please note that this plan replace path information is only populated by Terraform 0.15 and later.

[bflad]

That was quick haha: https://github.com/hashicorp/terraform-json/releases/tag/v0.20.0

[gdavison]

It would be good to have two variants: one that passes as long as the ReplacePaths contains the given set (e.g. ExpectResourceReplacePathsContains) and one that must be a strict equality (e.g. ExpectResourceReplacePathsEquals)