Open austinvalle opened 3 months ago
Not in any way saying these are better, but a few other potential approaches here might be:
(*big.Float).Text('f', -1)
for number comparisons, since the internal *big.Float
details differing may not necessarily matter to the intention of the assertion*big.Float
precision matches 512 bit precision and raising an error if not -- ostensibly this might be pretty annoying for developers though unless we potentially offer a helper(*big.Float).SetPrec(512)
-- I don't think we should have to worry about modifying the asserted value in this case unless the precision was actually given as higher and doing this would lower it (maybe then it could raise an error) although I think we would want to verify in these cases if the given value could already be "wrong"/unequal even if we "fix" the precision.Curious what you think!
My biggest sticking point would be altering the general expectation that the input value to knownvalue.NumberExact
wasn't "exactly" used in comparisons, although I'm not sure if we already do something like that in plugin framework 🤔 .
Developers who aren't worried about the precision could just compare it with a knownvalue.Float64Exact
, although that might not match with the schema 😕 .
Would be interesting to hear more from provider developers attempting to use this and their expectations
terraform-plugin-testing version
Use cases
When using
knownvalue.NumberExact
, it's possible to get confusing error messages in the situation where the provided*big.Float
does not match the value parsed from ajson.Number
because of the mantissa using something likebig.NewFloat
.Example
Test error
What can make this more confusing is when it accidentally is correct and the test passes 😅 :
Workaround
You can workaround this by creating the
*big.Float
exactly how the internal state check logic/Terraform creates it. Fixing the initial example in this issue:Proposal
Improve the error message to also include the precision/rounding/mantissa information to make it more apparent why two floating point numbers don't match. Perhaps we could also make a suggestion about how best to create the
*big.Float
value if a comparison doesn't match because of the mantissa.References