pactflow / pact-protobuf-plugin

Pact plugin for Protobufs and gRPC
MIT License
16 stars 8 forks source link

discrepancies between matchers syntax in pact-go and matcher syntax in pact-protobuf-plugin #49

Open dnozay opened 9 months ago

dnozay commented 9 months ago

Hello - thank you for your work on the project!

Here are the matching rules that I thought would work everywhere https://github.com/pact-foundation/pact-plugins/blob/main/docs/matching-rule-definition-expressions.md

The pact-go repo has quite a lot of testcases.

syntax supported

I see discrepancies between the 2 syntax supported.

  1. example in pact-protobuf-plugin's readme

    "email", "matching(regex, '\\w+@[a-z0-9\\.]+', 'test@ourtest.com')"
  2. example syntax in pact-go's matching test code

    {
    "pact:matcher:type": "regex",
    "value": "myawesomeword",
    "regex": "\\w+"
    }

matching on maps

  1. example in pact-go's consumer docs
Matcher Min. Compatibility Description
... ... ...
EachKeyLike(key, template) V3 Object where the key itself is ignored, but the value template must match. Useful for dynamic keys.
... ... ...
  1. matcher struct in pact-go
type eachKeyLike struct {
    Specification models.SpecificationVersion `json:"pact:specification"`
    Type          string                      `json:"pact:matcher:type"`
    Contents      interface{}                 `json:"value"`
}
  1. pact-protobuf-plugin's readme section "matching on map fields"

You could define a test like

    "request": {
        "labels": {
          "pact:match": "eachKey(matching(regex, '\\d+', '')), eachValue(matching(regex, '(\\w|\\s)+', '')), atLeast(1)",
          "100": "this is a label"
        },
        "ok": "true"
    }

So I don't know if I'm just looking at way old docs in pact-go and just expecting similar syntax to work everywhere, including with pact-protobuf-plugin or if that's an area where we could improve.

for context, in case someone wants to spend time fixing it

ideal situation (for me)

https://github.com/pact-foundation/pact-go/blob/master/examples/consumer_v4_test.go

I really liked the builder approach and the different matchers that are there for the HTTP side of things / plain json:

...
WillRespondWith(200, func(b *consumer.V4ResponseBuilder) {
    b.
        Header("Content-Type", S("application/json")).
        JSONBody(Map{
            "datetime":       Regex("2020-01-01", "[0-9\\-]+"),
            "name":           S("Billy"),
            "lastName":       S("Sampson"),
            "superstring":    Includes("foo"),
            "id":             Integer(12),
            "accountBalance": Decimal(123.76),
            "itemsMinMax":    ArrayMinMaxLike(27, 3, 5),
            "itemsMin":       ArrayMinLike("thereshouldbe3ofthese", 3),
            "equality":       Equality("a thing"),
            "arrayContaining": ArrayContaining([]interface{}{
                Like("string"),
                Integer(1),
                Map{
                    "foo": Like("bar"),
                },
            }),
        })
}).
...

and I wish we had the same syntax sugar for GRPC interactions.

YOU54F commented 2 months ago

Plugin matchers are different to the regular pact core matchers.

gh docs: https://github.com/pact-foundation/pact-plugins/blob/main/docs/matching-rule-definition-expressions.md website docs: https://docs.pact.io/implementation_guides/pact_plugins/docs/matching-rule-definition-expressions

syntax sugar would be nice to create a typed DSL but this would need to be considered potentially for all plugins, so the raw untyped approach is the trade off