Previous implementation depended on tab alignment. This worked
when the output was not prepended with anything, but would break
if the output was prepended with further spaces (which can occur
in environments like IntelliJ test runners). This commit fixes it
so that the output is always aligned logically.
Fixes#83
- NoError prints the error message on the next line, unquoted, which makes multiline error messages much clearer. Sample of an error message which includes a multiline stacktrace:
Error: Received unexpected error:
Hi!
/Volumes/Pouch/Users/russegan/dev/go/src/gitlab.protectv.local/ncryptify/client.git/client_test.go:27 (0x75c8c)
TestNew: assert.NoError(merry.New("Hi!"), "with message")
/usr/local/Cellar/go/1.7rc1/libexec/src/testing/testing.go:610 (0x70a01)
tRunner: fn(t)
/usr/local/Cellar/go/1.7rc1/libexec/src/runtime/asm_amd64.s:2086 (0x5d131)
goexit: BYTE $0x90 // NOP
Messages: with message
- Error,NoError,and EqualError now don’t inline the user’s extra messages. user’s messages are printed in the “Messages:” section, as with all other assertions.
- EqualError now avoids isNil(), mirroring the changes already made to Error and NoError.
- Equal, EqualValues, and EqualError now print the expected and actual values each on a newline, aligned vertically, which makes it easier for a human to visually detect the differences. Examples:
Error: Error message not equal:
expected: ”no failure"
recieved: “failure"
Messages: with message
Error: Not equal:
"high" (expected)
"low" (actual)
Messages: with message
- EqualValues uses the same value formatting and diff output as Equal for consistency
Go 1.7 subtests are called directly from testing.tRunner, not from the
test that contains the t.Run call. Because of this, the call stack
doesn't contain a function starting with Test, Benchmark, or Example,
causing assert.CallerInfo() to run off the end of the call stack and
return nil.
Look for testing.tRunner explicitly to solve this problem, and return
the list of callers if we do run off the call stack so that if there's a
similar problem in the future we still get an inflated stack trace
rather than no trace at all.
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)".
failNower is for internal use and we must not export it. Since we just
exported it a couple of days ago is unlikely this breking change will
affect anybody.
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 `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.
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.