This addresses vague and misleading output when asserting on the
equality of two values of differing numeric types.
Example: assert.Equal(t, int64(123), int32(123))
Previously, the user would have received a vague message claiming that
123 != 123. Now the message will read "int64(123) != int32(123)".
Implemented new InEpsilon by calculating the relative error and
comparing it to the expected epsilon rather than calculating the
acceptable margin and using InDelta.
While doing so we got rid of the false failure when the actual value
was zero.
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>
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.
Extend tests for NotEqual, Len and add tests for Condition, InEpsilon.
Add tests for Assertion.Condition, Assertion.InEpsilon, Assertion.InDelta
Fix a bug for Assertion.InDelta, Assertion.InEpsilon having incorrect signature.
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.