https://linen.dev logo
Join Slack
Powered by
I was wondering if there is a way to create custom...
# help
k
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
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
Copy code
public class CustomPattern extends StringValuePattern {
    public CustomPattern(@JsonProperty("customPattern") String expectedValue) {
        super(expectedValue);
    }
    ...
}
JSON:
Copy code
{
  "request": {
    "bodyPatterns": [
      {
        "customPattern": "expectedValue"
      }
    ]
  }
}
t
There’s an extension point you can use to achieve this: https://wiremock.org/docs/extensibility/custom-matching/
k
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
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
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.
59 Views
Open in Slack
PreviousNext
Powered by