Diffs no longer call string()

[b-gupta]

https://github.com/stretchr/testify/blob/master/assert/assertions.go#L1654

	// DisableMethods specifies whether or not error and Stringer interfaces are
	// invoked for types that implement them.

Not sure why this was added by default. Can we make this configurable or remove it?

[tjanez]

To save others some time, here is the relevant line:

testify/assert/assertions.go

Line 1658 in ab6dc32

DisableMethods: true,

that configures the go-spew's behavior.

And here is the PR that changed this: #895.

[mitar]

I got bitten by this as well. :-(

[brackendawson]

Given that the assertions never call such methods I think we should not be showing their output in diffs. There is a risk of saying "these two things are different and here is a diff showing that they are identical".

@mitar can you give a more detailed experience report explaining how this bit you?

[mitar]

It is simple, if errors contain private fields, diffing them does not return anything useful. While Error() might return useful data.

[brackendawson]

Yea ok, that's a common theme. Private struct fields are used in comparisons with == and reflect.DeepEqual but are otherwise completely inaccessible.

For most custom errror types I've seen in the wild their Error() method does not yeild all of their fields. In fact I've seen many not yield public fields. So I definately hold a position against reversing the change.

While we decide whether to expose the configuration, you can put the method output into msgAndArgs to add additional information to the error output:

assert.Equalf(t, expected, actual, "\nexpected: %q\nactual:  %q", expected.Error(), actual.Error())

[mitar]

For most custom errror types I've seen in the wild their Error() method does not yeild all of their fields.

But the difference is between having {} struct without even an error message shown (because it is stored in a private field) and having at least an error message string.

While we decide whether to expose the configuration, you can put the method output into msgAndArgs to add additional information to the error output:

Yes, but this is really tedious and it works only at top-level, but not if error is nested somewhere in a struct (not common, but still).

Maybe a solution could be to check for a custom interface method defined by this package and used only when diffing which expects to dump the whole struct into string?