https://linen.dev logo
#help
Title
# help
k

Kyle Winkelman

01/09/2024, 9:35 PM
I was wondering if there is a way to create custom StringValuePattern and still support json configuration files (I believe not). To take the question a step further could we create a StringValuePatternExtension that would register itself to the StringValuePatternJsonDeserializer?
a

Andrew Ripley

01/09/2024, 11:30 PM
Hey! I have been diving into wiremock recently, so I thought I would take a stab at this. Could you help me understand your question a bit more? Is the request for a way to match patterns using something like regex on a json formatted configuration file?
k

Kyle Winkelman

01/10/2024, 12:36 AM
Copy code
public class CustomPattern extends StringValuePattern {
    public CustomPattern(@JsonProperty("customPattern") String expectedValue) {
        super(expectedValue);
    }
    ...
}
JSON:
Copy code
{
  "request": {
    "bodyPatterns": [
      {
        "customPattern": "expectedValue"
      }
    ]
  }
}
t

Tom

01/10/2024, 9:41 AM
There’s an extension point you can use to achieve this: https://wiremock.org/docs/extensibility/custom-matching/
k

Kyle Winkelman

01/10/2024, 1:01 PM
Thanks @Tom, I was trying to avoid using custom-matcher, because when something doesn't match the only information you get in the diff is that the custom-matcher didn't match. And my other qualm with custom-matcher is that you must parse the Parameters for every request. https://github.com/wiremock/wiremock/issues/2486
t

Tom

01/10/2024, 6:13 PM
Yeah, agree we need to support extensibility in the diff feature. I’ve also been considering allowing additional named matchers like the core ones to be added via extensions, but this probably isn’t going to get any airtime soon unless someone in the community wants to pick it up. One workaround you might try is to use the new sub-events feature and attach custom match failure info that way. At least then it will be exposed in the request log.
k

Kyle Winkelman

01/10/2024, 7:54 PM
Would you be willing to take a look at https://github.com/kyle-winkelman/wiremock/tree/customMatcherDiff. It is my initial thoughts on allowing a custom matcher display additional information.
Also thinking long term, could we allow the custom matcher to get a handle on the MappingBuilder, so it can add as many existing matchers as it wants. For example, graphql would have POST, url = /graphql, header = application/json, equalToJson for variables and operationName, matchesJsonSchema, and a custom equalToGraphqlQuery for query. By allowing the custom matcher to register all of these your json config file would be a lot more concise and you get the benefit of existing diff.
8 Views