Add ability to perform assertions against the plan before and after TestStep Config is executed

[storey247]

SDK version

1.13.1

Use-cases

There are some situations where ExpectNonEmptyPlan does not permit enough flexibility/granularity in testing, and it could be beneficial to check that a proposed plan meets the requirements of the testing scenario. For example:

• There may be cases where you expect a non-empty plan, but your logic is flawed, so the reason your plan isn't empty is incorrect
• You want to want to check for a specific element to present within the plan before or after the test has applied the plan, an example could be that you want to ensure that your provider logic correctly flags specific resource properties for modification.
• You are working with very costly resources that take a lot of time to provision, thus slowing your tests drastically, or the resources could incur a large cost overhead. It would be useful to have the ability to ensure that the plan is correct before applying, so that the test can fail fast and save time/money.

Attempted Solutions

I haven't attempted anything yet, but have spent time looking into how TestStep functions and can see how this could easily be included.

Happy to work on this issue though 😄

Proposal

• Similar to step.PreConfig add a new property to TestStep named step.PrePlanValidate which will take a func definition.
• Similar to step.Check add a new one step.PlanValidate which would take a func similar to TestCheckFunc and allow us to write specific tests on the plan output.
• Alternatively TestCheckFunc could be extended to provide the plan that was generated as part of the refresh step as a parameter. This would allow easy testing of state and the final plan for any inconsistencies.

References

N/A

[bflad]

I believe most of this is covered nowadays with plan checks, which is an extensible interface with access to all machine-readable plan information. We introduced a few built-in plan checks already (with some more coming in terraform-plugin-testing v1.6.0 and planned for a future v1.7.0), but if you have suggestions for additional built-in plan checks that haven't been suggested already, please create a feature request. Thanks!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.