Hey, I’m currently contemplating an enhancement to...
# wiremock-java
Hey, I’m currently contemplating an enhancement to WireMock Scenarios as was hoping to get some feedback. Background: some folks who are running WireMock in shared environments (or ones with concurrent activity) find it a problem when a scenario’s state is updated by another user/session, affecting theirs. I’m proposing to support adding specific request parameters (headers, query, cookies etc.) to the scenario’s state key, so that e.g. if you include
as an element, you’ll get a unique state machine for every value of the session key, rather than a single global state machine (for this scenario). I contemplated just making the scenario key templated, but realised it might be good in future to be able to retrieve scenarios by name via the API and see a breakdown by session/token/whatever. So I think the additional key elements should be a list of request parameter types/keys. So, the JSON API would look something like this:
Copy code
  "scenarioName": "To do list",
  "requiredScenarioState": "Started",
  "scenarioStateKey": [{
    "type": "cookie",
    "name": "JSESSIONID"
  "request": {
    "method": "GET",
    "url": "/todo/items"
  "response": {
    "status": 200,
    "body": "...
Have any of you experienced this particular issue before? If so, do you think this be a good solution?
What would the full list of scenario state key types be? I'm guessing: • cookie • queryParam • header
I think those 3 would be sufficient. I’d want to see some real-world usage before adding e.g. the ability to select body elements.
It looks like you're planning to allow multiple things in the
- do you expect that to be necessary?
Or just a case of making the API evolvable
I can’t think of any obvious scenarios, but OTOH it’s not that much more complicated to permit >1 key element, but might be a pain to add that later if it turns out to be needed.
👍 1
I guess there’s a simpler rendering of it e.g.
Copy code
"scenarioSessionKey": { "type": "cookie": "name": "JSESSIONID" }
I wondered if we could start with that, then if someone has a concrete requirement you could add
"scenarioSessionKeys": []
and the former would become a shorthand for the latter with one key.
Do you think it’s clearer describing it as “session key(s)” specifically or something more generic? I’m wondering if people will be confused/put off if the thing they’re segmenting on isn’t a session per se.