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
The v1.7.0 release introduced the experimental knownvalue package for writing value-specific assertions against known resource attribute and output values. This initially exposed checks such as:
Bool(value bool)
Float64Exact(value float64)
Int64Exact(value int64)
StringExact(value string)
The values for these checks may not be known upfront with a developer hardcoding the value. For example in #295, computed attribute values are compared to an API response type where the struct fields are pointers. Attempting to declaratively dereference the field value pointer to use the existing known value checks would almost undoubtedly cause a panic when running the test since the dereferencing operation would occur during compilation while its still nil.
Proposal
Caveat: This proposal only suggests asserting values that are already pointers to Go built-in types, not potentially extracting values into the pointer. That proposal should be submitted separately and has many more considerations of whether it should be offered natively or what form it should take.
Verify whether this testing pattern is prevalent in the ecosystem or might become prevalent with the newer checks. If not, do nothing.
Introduce the following into the knownvalue package:
BoolPointer(value *bool)
Float64PointerExact(value *float64)
Int64PointerExact(value *int64)
StringPointerExact(value *string)
If the given value argument is nil, return an error that alludes to using the Null check instead. This would be intended to prevent developers from testing implementation errors and from relying on these checks for null checking.
Otherwise, the check logic can dereference the pointer and perform an exact equality check.
terraform-plugin-testing version
Use cases
The v1.7.0 release introduced the experimental
knownvalue
package for writing value-specific assertions against known resource attribute and output values. This initially exposed checks such as:Bool(value bool)
Float64Exact(value float64)
Int64Exact(value int64)
StringExact(value string)
The values for these checks may not be known upfront with a developer hardcoding the value. For example in #295, computed attribute values are compared to an API response type where the struct fields are pointers. Attempting to declaratively dereference the field value pointer to use the existing known value checks would almost undoubtedly cause a panic when running the test since the dereferencing operation would occur during compilation while its still
nil
.Proposal
Caveat: This proposal only suggests asserting values that are already pointers to Go built-in types, not potentially extracting values into the pointer. That proposal should be submitted separately and has many more considerations of whether it should be offered natively or what form it should take.
Verify whether this testing pattern is prevalent in the ecosystem or might become prevalent with the newer checks. If not, do nothing.
Introduce the following into the
knownvalue
package:BoolPointer(value *bool)
Float64PointerExact(value *float64)
Int64PointerExact(value *int64)
StringPointerExact(value *string)
If the given
value
argument isnil
, return an error that alludes to using theNull
check instead. This would be intended to prevent developers from testing implementation errors and from relying on these checks for null checking.Otherwise, the check logic can dereference the pointer and perform an exact equality check.
References
The text was updated successfully, but these errors were encountered: