Pre-launch feedback

[tomakehurst]

I thought this would be a better feedback medium than Twitter DMs.

Here are my thoughts after a quick play with the plugin:

• When editing a mapping, not all the fields of the form are populated with the existing values.
• The path/regex/partial dropdown is a bit confusing - not sure what partial means and how it maps onto WM's underlying URL matching options.
• In the mappings list view, longer URLs overlap with the status code.
• Priority field has no label when populated and being a simple integer it's not necessarily obvious what it is
• I can't set the predicate for the request body. Not clear by what method it would attempt to match, and it's definitely useful to have control over this.
• I can only specify one request body parameter, whereas WireMock permits many. This can be useful if you're matching on e.g. a set of JSONPath expressions targeting different bits of the payload
• Doesn't support matching on cookies (other than by matching the header)
• Doesn't provide a way for me to configure proxy or fault mappings (maybe you consider this too much for now?).
• Might be a nice idea to support the new (admittedly as yet undocumented) name field on stub mappings.
• When setting the host it might be useful to be able to set the protocol, for cases where folks have deployed it behind HTTPS termination.
• Would be nice to be able to view the request journal.

[mwinteringham]

Thanks for @tomakehurst I will probably have question to follow this up but I will get working on this feedback.

[mwinteringham]

@tomakehurst I have been trying to reproduce the issue of not all the fields of the form are populated with the existing values. Can you shed some more light onto what fields specifically are causing a problem?

[tomakehurst]

For me the only fields that get preserved seem to be URL, URL match type and method.

[mwinteringham]

Hi @tomakehurst I've made some progress on the issues you've risen but I have a few more questions to ask you:

Would be nice to be able to view the request journal I'm not entirely sure what the request journal is and how I access it. I've looked at the Docs but I'm struggling to understand how to access it and use it.

I can't set the predicate for the request body. Not clear by what method it would attempt to match, and it's definitely useful to have control over this. Again I'm not sure what you mean by setting the predicate, can you give me more details? I am updating the extension to take multiple matching request payloads, is this related to predicates for request bodies?

[mwinteringham]

Done a bit more research on the predicates for requests and I now understand what you mean. I have been calling them keys since I have used the JSON mappings to inform requirements.

Currently, the predicate/key is decided under the hood by doing a lookup on the first character of the request body. I have made an assumption that how each request is started is unique to the type of predicate/key you want to use.

switch (requestPayload[i].charAt(0)) {
      case '{':
          payload.request.bodyPatterns.push({
            "equalToJson": requestPayload[i]
          });
          break;
        case '$':
          payload.request.bodyPatterns.push({
            "matchesJsonPath": requestPayload[i]
          });
          break;
        case '<':
          payload.request.bodyPatterns.push({
            "equalToXml": requestPayload[i]
          });
          break;
        case '/':
          payload.request.bodyPatterns.push({
            "matchesXPath": requestPayload[i]
          });
          break;
      }

I think this could be improved by giving some feedback on what the extension has assumed the request body predicate/key to be.

[mwinteringham]

I have gone over the list and fixed bugs, implemented some of the suggestions and hived off other features in #4 #5 #6 #7

[tomakehurst]

Sorry for the delayed reply. The request journal is just the log of received requests, accessible via /__admin/requests