The `Implements` test was just showing a string instead the name of the
object that was not implementing the interface. Now the type of the
object is shown.
The NotNil assertion had an error in its handling of typed nil values.
This change makes use of the helper function isNil (used by the Nil
assertion). The helper function has correct handling of typed nil
values and when negated provides the expected semantics for
`assert.NotNil(t, x)`.
if x == nil {
assert.Fail(t, "is nil", x)
}
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.
Previous behavior was to print the error with no delimiters:
No error is expected but got unexpected character in stream
New behavior is to print the error surrounded by quotes:
Recieved unexpected error "unexpected character in stream"
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.
