assert: EqualValues does not check for overflows

[vispariana]

When asserting two numeric values with EqualValues, it passes if one is the overflowed value of the other.

example: https://go.dev/play/p/KZsFh7FnBVc

func TestEqualValues(t *testing.T) {
	var a int8 = 14
	var b int = 270
	assert.Equal(t, b, a)       // fails because of type mismatch
	assert.EqualValues(t, b, a) // passes
}

[tscales]

testify/assert/assertions.go

Line 161 in 882382d

if expectedValue.IsValid() && expectedValue.Type().ConvertibleTo(actualType) {

Go Allows for Ints to be converted to Int8s, hence the ConvertibleTo method returns true. A check would probably needed to be added that the Value of Expected > maxSize of the actual type before doing the DeepEqual call.

[vispariana]

testify/assert/assertions.go

Line 161 in 882382d

if expectedValue.IsValid() && expectedValue.Type().ConvertibleTo(actualType) {

Go Allows for Ints to be converted to Int8s, hence the ConvertibleTo method returns true. A check would probably needed to be added that the Value of Expected > maxSize of the actual type before doing the DeepEqual call.

How about checking it both ways instead of looking at max size?

assume we have var a A and var b B. if A is convertible to B then B is also convertible to A. So maybe we can just check if:
B(a) == b && A(b) == a

[tscales]

assume we have var a A and var b B. if A is convertible to B then B is also convertible to A. So maybe we can just check if: B(a) == b && A(b) == a

var b can't be assumed convertible in all cases. For example: when a is an int and b is a string, the assertion would panic if we tried to introduce actualValue.Convert(ExpectedType)

https://go.dev/play/p/BKML-vPu4l_N
https://go.dev/play/p/eOi-PI8CLhk

[vispariana]

I didn't know that conversion existed. Thank you!
I still believe that's the way to go though. If a and b are not convertible to each other, they are not "EqualValues". That's testify/assert's the current approach, because no order is implied on the two parameters, which leads to inconsistencies like this:

https://go.dev/play/p/XaCM39GdJum

So I think we'd be fine with adding a reverse convertibility check to prevent the panic you mentioned.

[arjunmahishi]

So I think we'd be fine with adding a reverse convertibility check

I don't think this will work. int8.ConvertibleTo(int) and int.ConvertibleTo(int8) both return true. I've raised a PR with a simple fix. We just need to ensure that we are converting smaller type to a larger type (int8 to int in this case). In the EqualValues function, the order of the arguments should not matter anyway.