What was your test testing? Was it the presence of the error, the presence
of a particular value, or the contents of the Error() string?

On Wed, 1 Jun 2016, 07:15 Joe Tsai notifications@github.com wrote:

Currently, in go1.6, different error values returned by errors.New(...)
are equal (in the sense of the reflect.DeepEqual usage) if they have the
same error message. This encourages people to write unit tests like the
following:

want := errors.New("archive/tar: header field too long or contains invalid values")if !reflect.DeepEqual(got, want) {
...
}

This is a poor test it assumes an exact error message and type for an
unexported error from a given package. Instead, we should cause DeepEqual
to always return false somehow by embedding some field in the concrete
errorString type that always compares to false for anything but itself.

Thus, I expect the following to happen:

a := errors.New("foo")b := errors.New("foo")

reflect.DeepEqual(a, a) // True
reflect.DeepEqual(a, b) // False (this is currently true)

We probably cannot change this in Go1 because the sheer number of tests
this would probably break, but it may be worth considering for Go2.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#15910, or mute the thread
https://github.com/notifications/unsubscribe/AAAcA6-SWX9Hy-I6M7NkX3-dB23j8V0gks5qHKT5gaJpZM4Iq92H
.

I'm closing this. Inside Google, most tests have been moving towards cmp.Equal, which makes it more obvious when you're doing comparisons in a forward incompatible way.

Although, I still occasionally see direct string comparisons on error strings, I haven't seen a test use reflect.DeepEqual on an error they created themselves in a while.