Additional Matchers

[peterstace]

A few additional generic matchers would be very useful, as they would eliminate most cases where custom single-use matchers are needed (at least for my uses cases).

I propose:

// Type creates a Matcher that matches values with the same dynamic type as x.
func Type(x interface{}) Matcher { ... }

// Length creates a Matcher that matches arrays, slices, strings, maps, and channels of length n.
func Length(n int) Matcher { ... }

// Field creates a Matcher that matches structs where the named field matches x.
func Field(fieldName string, x interface{}) Matcher { ... }

// AllOf creates a Matcher that matches values matching all supplied matchers.
// Each matcher is checked in the order provided. If a particular supplied matcher
// doesn't match, later matchers are not considered (i.e. early return on match failure).
func AllOf(matchers ...Matcher) Matcher { ... }

// Index matches arrays, slices, and strings where the i'th element matches x.
func Index(i int, x interface{}) Matcher { ... }

I can see two approaches to implementing these. The length matcher could either panic or just return false if an attempt is made to match against a value that is not an array, slice, map, string or channel. Similarly, the field matcher could either panic or just return false if an attempt is made to match against a value that isn't a struct, or a struct that doesn't have the named field. Again, the index matcher could either return false or just panic if an attempt is made to match against a value that isn't an array, slice, or string.

I think panicking is a better option, since attempting to match a value with an incompatible matcher (e.g. trying to match a slice with a field matcher) seems much more likely to be a bug in a test rather than a legitimate use-case for matching. Either way would be fine though.

I'm more than happy to provide a pull request with the implementation. I just wanted to get some feedback on the idea and whether you would be open to this change before I getting too carried away with implementing things.

[liron-l]

@peterstace, what do you think about the proposed matcher in #5

[dsymonds]

Sorry, I'm not keen on loading the gomock core up on every variation. I suggest publishing your own package with those, and gomock can adopt any that get considerable traction.

[peterstace]

No worries, thanks @dsymonds