New Matcher Request: Matcher that verifies the length of a string

[timvahlbrock]

Our application uses the jakarata validation's Size annotation to limit the length a string can have. I tried representing this using regular expressions, but ran into several issues with how regex's counts characters (each symbol is one char) vs how they are counted in java (how many utf-16 unicode chars are used), see pact-foundation/pact-jvm#586. Maybe this can be solved using a dedicated matcher in the pact specification? It would probably also need to contain information on how the characters are counted, maybe having the options of different charactersets or bytes is sufficient.

[mefellows]

Would you mind elaborating on your use case a little further? Whilst this might be a useful thing at the validation layer when writing to a database, it might be too restrictive in a general use case in Pact. I'm not saying it's wrong, but it does feel like we're enforcing a schema on a provider, which is not really the intent of contract testing.

From this article:

Only make assertions about things that will affect the consumer if they change

Avoid the temptation to make assertions about general business rules that you know about the provider (eg. the customer ID is expected to be in the format [A-Z][A-Z][A-Z]-\d\d\d). Only make assertions about things that would affect your consumer if they changed (eg. a link must start with http because your app is expecting absolute URLs, and would error if it received a relative one). This allows the provider to evolve without getting false alerts from unncessarily strict pact verification tests.

[timvahlbrock]

Hm. I see what you mean. At the current point it would actually affect the consumer, as we're currently asserting that the string wouldn't be too long and will reject the entire message otherwise. This is mainly caused by us still relying on code generated from a schema and probably wouldn't be switching away any time soon to a tolerant reader approach.

Another aspect of this is that I wrote a helper construct inspired by something similar like the WithBodyMatch available in pact-go https://docs.pact.io/implementation_guides/go/docs/consumer#auto-generate-matchers-from-struct-tags for our project, therefore not specifying explicit example values. This failed the contract tests because the generated example value might be too short. However, I'm currently handling this by just using a type matcher on the string without further restrictions and using the length information only to generate the example value. I think that would also be a valid way of moving forward.

[timvahlbrock]

I'm not sure whether a string limitation would make a string unnecessarily brittle, because if the consumer is expecting a string to not be longer than a certain size for storage, display or interpretation reasons, I would think of it as a valid response if the provider provided a string longer than that. However, if the provider does not modify their example value beyond the expected limit when increasing the allowed string length it would be impossible for impact the differences in expectations.

[timvahlbrock]

So what I get from this is that while catching a provider exceeding the limit expected by the consumer would be nice to catch using contract tests, it would only be possible if the provider actively tries to exhaust those string limits when choosing the provided example values. Right?