Add a way to wait until a Subscriber connects to a Publisher

[drigz]

I'm working on writing automated tests for rosjava nodes. The node I'd like to test publishes a message in response to a trigger. In the test, I'd like to simulate the trigger and assert that the message is published.

My implementation is as follows:

1. Start a rosjava master.
2. Start the node-under-test.
3. In the test, create a Subscriber for the topic.
4. Wait for the node-under-test's Publisher to connect to the Subscriber.
5. Simulate the trigger.
6. Assert that the MessageListener's onNewMessage method is called within a given timeout.

However, I'm struggling with "Wait for the node-under-test's Publisher to connect to the Subscriber". My implementation looks like this:

    Subscriber subscriber = connectedNode.newSubscriber(topicName, messageType);
    subscriber.addMessageListener(messageListener);

    CountDownSubscriberListener subscriberListener = CountDownSubscriberListener.newDefault();
    subscriber.addSubscriberListener(subscriberListener);
    if (!subscriberListener.awaitNewPublisher(timeout, unit)) {
      throw new RuntimeException("timeout waiting for publisher to connect");
    }

But there is a race condition - if the Publisher connects before the test calls addSubscriberListener, the test cannot know that a Publisher has connected.

One way around this would be to add a Subscriber.hasPublishers() method, analogous to Publisher.hasSubscribers(). To avoid breaking compatibility with existing code (is this a concern?) we could add it to DefaultSubscriber, at the cost of a more fragile test.

@ernestmc @jubeira What do you think? Is there a better way to write this test?

[jubeira]

Hi @drigz, sorry for the delay; I'm travelling abroad right now.

I like the idea of a hasPublishers method, as it makes sense to have an analogue method for the subscriber.

I can't think of a better way to do the test right now. I'm not familiar with the mechanism behind latched publishers, but maybe something similar can be done on the subscriber side.

In any case, I think compatibility is desired, unless there's a good reason to break it.