How to test a verticle that does not wait for acks to its messages?

Question

I want to test a worker verticle that receives requests over EventBus and sends the results also over EventBus. A single request may result in 0,1,2,... responses - in general cases we don't know how many responses we'll get.

The business logic is that requests are acked once the processing is complete, however the responses are sent in "fire and forget" manner - therefore we only know the responses were sent, not necessarily that they were delivered already.

I am writing a test for this verticle.

The test code is planned to be like this:

1. set up consumer for responses
2. send a request
3. wait until request is acked by the worker verticle
4. wait until consumer finishes validating the responses

The problem here is step 4 - in general case we don't know if there are still some responses in flight or not.

A brute force solution is obviously to wait some reasonable time - a few milliseconds is usually enough. However. I'd prefer something more conceptual.

A solution that comes to my mind is this:

1. send some request for which we know for sure that there would be a single response;
2. wait until the consumer receives the corresponding response. That should work, but I dislike the fact that I pump two messages through the SUT instead of just a single one.

A different solution would be to send one extra response from test code, once we have a confirmation that the request was processed - but would it be considered to be the same sender? The EventBus only guarantees delivery order from the same sender, not from different ones. The test doesn't run in cluster mode, all operations are performed on the same machine, though not necessarily in the same thread.

Yet another solution would be to somehow check that EventBus is now empty, but as I understand, this is not possible.

Is there any other (better) solution?

Answer 1

The solution I would choose now (after half a year more experience with vertx/EventBus) is to send two messages. The second message would get acked only after the processing of the first one is complete.

This would only work if you have a single consumer so that your two messages can't be processed in parallel.