Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dnozay opened this issue Feb 14, 2024 · 1 comment

Comments

@dnozay
Copy link

dnozay commented Feb 14, 2024

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\\.]+', '[email protected]')"
  1. 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
Copy link
Member

YOU54F commented Sep 26, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants