Hi all! We were thinking about somehow integrating StructMatcher and implementing

GetString()

method to Matcher type, so that instead of doing this:

grpcInteraction := struct {
	PactProtoService string `json:"pact:proto-service"`
	Request          any    `json:"request"`
	Response         any    `json:"response,omitempty"`
}{
	PactProtoService: "MyService",
	Request: map[string]interface{}{
		"user_id": "matching(integer, 100)",
	},
	Response: map[string]interface{}{
		"first_name": "matching(type, 'random')",
		"last_name":  "matching(type, 'random')",
	},
}

We can do below instead:

grpcInteraction := struct {
	PactProtoService string `json:"pact:proto-service"`
	Request          string `json:"request"`
	Response         string `json:"response,omitempty"`
}{
	PactProtoService: "MyService",
	Request: StructMatcher{
		"user_id": Integer(100),
	}.ToString(),
	Response: StructMatcher{
		"first_name": Like("random"),
		"last_name":  Like("random"),
	}.ToString(),
}

For example

matchers.Integer(100).ToString()

would be

{"specification":"3.0.0","pact:matcher:type":"integer","value":100}

. I tried it on like which Integer users. However, I'm running into the issue of

Request to configure interaction failed: Failed to process protobuf: Field values must be configured with a string value, got Object {"pact:matcher:type": String("integer"), "specification": String("3.0.0"), "value": Number(100.0)}

I learnt that matching evaluation is not done recursively https://pact-foundation.slack.com/archives/C9UTHTFFB/p1712026514061369?thread_ts=1711759161.767629&cid=C9UTHTFFB, so I was wondering if you know there's another way we can get the string representation of match expressions? Or is there a way to bypass the recursion issue?

I think I understand what you’re trying to do. You want to use the Matchers in your plugin tests? This is probably going to expose a misunderstanding on my part between an expression and a matcher. I haven’t tried, but I didn’t think you could use Matchers in plugins - you need to use expressions. @rholshausen mind confirming this? Could you elaborate a bit further on the mental model for expressions and matchers? It seems like an expression can be a matcher, whilst also having other properties.

An expression gets parsed into three things: a matcher, an example value and an optional generator.

So as a follow up, when using the FFI methods (

pactffi_with_body

,

pactffi_with_header_v2

etc.), can you use either an expression or a matching rule? Does this also mean plugins can use either, or is that entirely up to the plugin author? I’m a little confused on the interfaces/boundaries, and where things can be used

So as a follow up, when using the FFI methods (

pactffi_with_body

,

pactffi_with_header_v2

etc.), can you use either an expression or a matching rule?

Yes

OK, thanks. Yes I recall the expressions being added in a recent PR but wanted to confirm my understanding. So @Rinka Yoshida that would be the answer to your question. You can’t use Matchers in the way you were hoping, and the Struct Matcher wouldn’t work (because it’s just sugar over a struct that converts struct tags to matchers).

create a similar thing though, that knows how to take a struct and serialise expressions.

Was trying to avoid this but good to see this is the way to go. That makes sense, thank you both for chiming in so fast!

No worries, happy to bounce ideas around on this front as you progress