Florin Lipan

@JamesSharkey Thanks for reporting. I don't have the capacity to work on this in the near future but I would gladly review a PR on this topic if you or...

@zacps would the solution proposed in https://github.com/lipanski/mockito/issues/92 work for you? if so, we could look into implementing that.

That's an interesting idea, but I wonder if there are use-cases where this could become a problem. Generally I prefer to be explicit here and I've seen other testing frameworks...

@s97712 as mentioned in https://github.com/lipanski/mockito/issues/95, I'm a bit sceptical about exposing the request object at the moment or in the near future. I also think this would make the interface...

nice catch and thanks for reporting. I would also favour #92 as a solution rather than going back to the `--test-threads=1` days.

@zacps I'm a bit sceptical about exposing the request object. I changed the request parsing implementation quite a few times in the past and I still don't consider the interface...

@chess4ever I think this could be solved with a new matcher, similar to https://github.com/lipanski/mockito/pull/43 (but as a matcher). we could introduce it as `Matcher::Partial(String)` or `Matcher::Partial(Vec)`

@WasabiFan thanks for raising the issue. I feel like your feature is a bit too specific for this crate, though we could revisit after https://github.com/lipanski/mockito/issues/92 (which touches the server part)...

hi @cpick I think this crate could include websocket support as long as it doesn't complicate things. the `http_muncher` crate that I use to parse http has some websocket support...

@sterlingjensen is there any way to allow mocking websockets without pulling in big dependencies? I'd prefer that, even if writing websocket tests would be a bit more verbose than without...