Skip to content
This repository was archived by the owner on Jun 27, 2023. It is now read-only.
This repository was archived by the owner on Jun 27, 2023. It is now read-only.

Additional Matchers #6

Closed
Closed
@peterstace

Description

@peterstace
Contributor

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.

Activity

liron-l

liron-l commented on Aug 6, 2015

@liron-l

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

dsymonds

dsymonds commented on Aug 6, 2015

@dsymonds
Contributor

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

peterstace commented on Aug 7, 2015

@peterstace
ContributorAuthor

No worries, thanks @dsymonds

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @dsymonds@peterstace@liron-l

        Issue actions

          Additional Matchers · Issue #6 · golang/mock