assert.Same: add type names to fail message

[egawata]

Summary

This PR adds a type names of testing values to a fail message of assert.Same().

Changes

Adds type names of testing values to a fail message of assert.Same(), which might be necessary to identify the cause of failing.

Motivation

Currently, when assert.Same() fails, it outputs a message with pointer values and its go-syntax representation of actual/expected values.

assert.Same() would fail when types of two values are different. The following test code would fail:

type Member struct {
	Name string
	Age  int
}

type MemberPtr *Member

func TestMember(t *testing.T) {
	m := &Member{"Niko", 18}
	p := MemberPtr(m)

	assert.Same(t, m, p)
}

However, it seems no difference between actual and expected in its fail message, because they point to the same object. It would be hard to know why the test fails from this message.

--- FAIL: TestMember (0.00s)
    same_test.go:20:
                Error Trace:    same_test.go:20
                Error:          Not same:
                                expected: 0xc000132198 &main.Member{Name:"Niko", Age:18}
                                actual  : 0xc000132198 &main.Member{Name:"Niko", Age:18}
                Test:           TestMember
FAIL
FAIL    command-line-arguments  0.234s
FAIL

This PR adds type names of two values. The output would be like this:

--- FAIL: TestMember (0.00s)
    same_test.go:20:
                Error Trace:    same_test.go:20
                Error:          Not same:
                                expected: 0xc00000e1b0 &main.Member{Name:"Niko", Age:18} (*main.Member)
                                actual  : 0xc00000e1b0 &main.Member{Name:"Niko", Age:18} (main.MemberPtr)
                Test:           TestMember
FAIL
FAIL    command-line-arguments  0.517s
FAIL

Related issues

[dolmen]

No tests provided.

[brackendawson]

#1742 included a change equivalent to this.

[brackendawson]

This format string is quite sensitive to the types used and sometimes duplicates details.

It's quite surprising that %#v formats MemberPtr(&Member{"Niko", 18}) as &Member{Name:"Niko", Age:18}

We need to include %T and %p, probably (%T)(%p) is the most conventional?

[ccoVeille]

Make sense,indeed

[egawata]

Thank you for comments. 😃
This PR is too old, and has merge conflicts.
I'll close this PR and re-create new one.