Comparting a float with NaN is always false so the assertion would always pass.
Added a check that either the actual or expected values are NaN.
InDelta will now fail if either the actual or expected value are NaN.
`ObjectsAreEqual` using `ConvertibleTo` causes the `ObjectsAreEqual`
function to be asymmetrical and producing incorrect assertions.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
in `ObjectsAreEqual`, `expectedValue.Convert(actualType)` was being called when
`actualType.ConvertibleTo(reflect.TypeOf(expected))` was true. This was a problem
for situations such as when expected was an int and actual was a string, since
ints are `ConvertibleTo` strings, but the reverse is not true.
Changing the ConvertibleTo check to `expectedValue.Type().ConvertibleTo(actualType)`
solves the issue.
The change in #94 resulted in using == to compare two values that might not be
comparable. Hence, this resulted in a panic for situations like:
ObjectsAreEqual(map[int]int{5: 10}, map[int]int{10: 20})
The fix is to use reflect.DeepEqual() instead.
The previous assert.ObjectsAreEqual() implementation is broken in go 1.4beta1:
x := uint64(3)
log.Printf("equal? %t", assert.ObjectsAreEqual(3, x))
This prints "true" under Go 1.3 and "false" under 1.4beta1 (amd64/darwin).
The reason is that the ObjectsAreEqual() was comparing two reflect.Value values
for equality using ==, but the behavior of that operation is apparently
undefined (https://code.google.com/p/go/issues/detail?id=9034). The fix is to do
the type conversion and then do the comparison between two interface{} values.
If the two values being tested are of compatible types, convert one
value to the other's type before comparing them. This allows
`assert.Equal(int64(123), uint64(123))` to pass.