This message was deleted.

Welcome

@Lee Turner When playing with the gRPC extension, I noticed the wiremock-grpc-demos standalone project was not working, so I created the PR: https://github.com/wiremock/wiremock-grpc-demos/pull/1 Not sure if I need to do something more to get this approved?

Hi. Many thanks for the PR. Could you post it in the #C053Y3N34C8 channel and it will be picked up from there

Hi @Ingmar van Dijk, welcome! It’d be great to hear your requirements for mocking streams. Is it just that you want to be able to return a pre-defined sequence of messages when a request message is matched, or something different?

@Tom For mocking streams, I would both need have the mocked stream emit pre-defined messages (possibly configurable at what rate). And also would need to be able to trigger when events are emitted. When doing so I would like to be able to add the data of the message to emit on the trigger request. This would allow me to write Gherkin scenarios where I have steps like:

When the gRPC stream source emits a HelloResponse with greeting 'Hello Tom'
...
When the gRPC stream source emits a HelloResponse with greeting 'Hello Lee'

OK, thanks for sharing this. Let me give this some thought. I can see how we could add an extra API endpoint that allowed you to programmatically send additional events. The tricky bit might be identifying the particular stream you want to send the messages on, although perhaps that could also be done using request matching so e.g. “send this message on all streams where the initiating request was for operation Y, with request message Y…“. Does this sound plausible? Or maybe there’s a better way you can think of?

At this time I’m using the Admin REST APIs (running Wiremock in Docker) to add my mappings. So in my scenario this sequence happens: Given the GreetingService reply stream emits a HelloResponse with greeting “Hello from Mapping” Which is implemented to create a mapping:

POST [<http://wiremock:8000/__admin/mappings>] - {'request': {'method': 'POST', 'urlPath': '/com.example.grpc.GreetingService/oneGreetingManyReplies'}, 'response': {'jsonBody': {"greeting": "Hello from Mapping"}, 'status': 200}}

This response with the stub-mapping including the id, for example

id1

Now my system under test connects to the mapped gRPC stream and receives the “Hello from Mapping” greeting. Up to this point, this is already working. Assuming the stream is still open, my test-case should be able to trigger another event. What I could imagine: When the GreetingService reply stream emits a HelloResponse with greeting “Hello from Triggered”

POST [<http://wiremock:8000/__admin/mappings/id1/emit>] - {'response': {'jsonBody': {"greeting": "Hello from Trigged"}, 'status': 200}}

I’m not sure whether the Wiremock Mappings are linked to the gRPC streams, but if that is the case, I would expect that anybody that connected to a specific mapping should receive the event.

The main concern is where you might have multiple calls happening concurrently to the same method. If your test case were to trigger more response messages there would need to be a way to ensure the ended up on the correct response stream, and not e.g. one initiated in a parallel test thread. Since there doesn’t seem to be a stream identifier available (publicly enough at least) that we could get hold of then use in the API call to add more messages, falling back on the match criteria is the only way I can think to do this (and this might be good enough for most cases).

Yes for my case that would be sufficient. I can make sure that all the tests depending on a specific stream run in sequence, and only other tests run in parallel.