You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should build an extensive test-suite for previewing changes to bridged provider resources. This will allow us to have confidence in bug fixes and bigger changes to our code.
For Diff we have arrived at the pattern of cross-testing a given schema/value combination against TF - comparing the number of changes/replaces but also recording the Pulumi and TF CLI previews displayed to users. The preview/plan recordings allow us to also test the end behaviour which users see as a result of our code.
The tests are defined in terms of:
a "high-level" value, represented by a go value (think "my_string", []stirng{"my_string"}, etc)
a TF schema and a valueMaker function which turns the high-level value into a concrete value admissible by the schema which can be used in cross-tests directly.
This pattern allows us to re-use some of the logic across schemas which would otherwise not accept compatible values.
The differences in the way the SDKv2 schemas and PF schemas are defined on the TF side means that we need to test these separately.
The text was updated successfully, but these errors were encountered:
We should build an extensive test-suite for previewing changes to bridged provider resources. This will allow us to have confidence in bug fixes and bigger changes to our code.
For
Diff
we have arrived at the pattern of cross-testing a given schema/value combination against TF - comparing the number of changes/replaces but also recording the Pulumi and TF CLI previews displayed to users. The preview/plan recordings allow us to also test the end behaviour which users see as a result of our code.The tests are defined in terms of:
"my_string"
,[]stirng{"my_string"}
, etc)valueMaker
function which turns the high-level value into a concrete value admissible by the schema which can be used in cross-tests directly.This pattern allows us to re-use some of the logic across schemas which would otherwise not accept compatible values.
The differences in the way the SDKv2 schemas and PF schemas are defined on the TF side means that we need to test these separately.
The text was updated successfully, but these errors were encountered: