Azure-sdk-for-java: [Question] How can I unit test EventProcessorClient?

[obarat]

Query/Question

I'm trying to add unit tests for my EventHub client class. The code looks like this:

public class MyEventHubClient {

  private EventProcessClient myProcessorClient;

  public MyEventHubClient() {
    myProcessorClient = new EventProcessorClientBuilder()
      .
      .
      .
      .processEvent(PROCESS_EVENT)
      .buildEventProcessorClient();
  }

  public final Consumer<EventContext> PROCESS_EVENT = eventContext -> {
    // do stuff 
  }

}

I want to test that when an Event is consumed, it is processed correctly. For testing HTTP calls, I use MockWebServer to prepare a mock response and then test that my code can handle the response correctly, is there a way I can prepare an event and actually execute the code in the EventProcessorClient?

Why is this not a Bug or a feature Request?

I dug through some of the existing unit tests but it seems like either the builder or the client itself is mocked, I couldn't find an example where an event is prepared and the code is executed fully.

Setup (please complete the following information if applicable):

• OS: Big Sur
• IDE : IntelliJ
• Version of the Library used: azure-messaging-eventhubs - 5.4.0

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• [x] Query Added
• [x] Setup information Added

[joshfree]

@conniey could you please follow up with @obarat

[conniey]

Hey, one of the things we use to test our client is to use this mockito feature: https://github.com/Azure/azure-sdk-for-java/wiki/Unit-Testing#mocking-final-classes

[obarat]

@conniey - Thanks for sharing the link, I took a look at it but I don't see how I can apply it in my situation. My goal is to test the code inside the PROCESS_EVENT function. How can I do that?

I see that I can mock the entire EventProcessorClient and add something like when(eventProcessorClientMock.receiveEvent()).thenReturn(preparedEvent), but that won't execute the code inside the PROCESS_EVENT function, right?

[conniey]

@obarat That's correct. Thinking more about it, breaking out your processEvent consumer would make the code a lot more testable because you no longer take a dependency on the processor class itself.

Application Code

class Program {
    public static void main(String[] args) {
        var aggregator = new EventAggregator();
        var processor = new EventProcessorClientBuilder()
            .processEvent(context -> aggregator.onEvent(context))
            .buildEventProcessorClient();
    }
}

class EventAggregator {
    void onEvent(EventContext eventContext) {
        // Do stuff.
    }
}

Test Code

class EventAggregatorTest {
    @Test
    void onEventTests() {
        // Arrange
        var aggregator = new EventAggregator();
        var eventContext = mock(EventContext.class);

        // Act
        aggregator.onEvent(eventContext);

        // Assert things about your aggregator.
    }
}

[obarat]

Thanks @conniey that's a great idea! Just before closing this issue, I'm wondering if you know about the second part of the question - about preparing an event and actually receiving it within a unit test (similar to the MockWebServer).

Edit: I guess that still leaves me with the problem of testing that it does call this method when a new event is consumed. If I mock the Client, I won't be able to tell that the onEvent method gets called?

[conniey]

about preparing an event and actually receiving it within a unit test (similar to the MockWebServer).

At the moment, we are working on mocking an AMQP server that delivers events, but it is not in existence yet.

Edit: I guess that still leaves me with the problem of testing that it does call this method when a new event is consumed. If I mock the Client, I won't be able to tell that the onEvent method gets called?

From a consumer of the client library's perspective, I think of EventProcessorClient as a black box. You assume that since we expose the APIs, the library will do the right thing and call your processEvent handler when an event is received. Otherwise, we'd be testing every third party dependency end-to-end (which I hope our libraries would do).

I hope this helps. :)

[obarat]

Thanks!