Asynchronous

In the last blog post, we saw how to test complex interactions through our apps using stubbed behaviors by Mockito. In this post, I’ll be talking about how to test RxJava components such as Observables. This one will focus on testing complex situations using RxJava as the library itself provides methods to unit test your reactive streams, so that you don’t have to go out of your way to set contraptions like callback captors, and implement your own interfaces as stubs of the original one. The test suite (kind of) provided by RxJava also allows you to test the fate of your stream, like confirming that they got subscribed or an error was thrown; or test an individual emitted item, like its value or with a predicate logic of your own, etc. We have used this heavily in Open Event Orga App (Github Repo) to detect if the app is correctly loading and refreshing resources from the correct source. We also capture certain triggers happening to events like saving of data on reloading so that the database remains in a consistent state. Here, we’ll look at some basic examples and move to some complex ones later. So, let’s start. public class AttendeeRepositoryTest { private AttendeeRepository attendeeRepository; @Before public void setUp() { testDemo = new TestDemo(); } @Test public void shouldReturnAttendeeByName() { // TODO: Implement test } }   This is our basic test class setup with general JUnit settings. We’ll start by writing our tests, the first of which will be to test that we can get an attendee by name. The attendee class is a model class with firstName and lastName. And we will be checking if we get a valid attendee by passing a full name. Note that although we will be talking about the implementation of the code which we are writing tests for, but only in an abstract manner, meaning we won’t be dealing with production code, just the test. So, as we know that Observables provide a stream of data. But here, we are only concerned with one attendee. Technically, we should be using Single, but for generality, we’ll stick with Observables. So, a person from the background of JUnit would be tempted to write this code below. Attendee attendee = attendeeRepository.getByAttendeeName("John Wick") .blockingFirst(); assertEquals("John Wick", attendee.getFirstName() + attendee.getLastName());   So, what this code is doing is blocking the thread till the first attendee is provided in the stream and then checking that the attendee is actually John Wick. While this code works, this is not reactive. With the reactive way of testing, not only you can test more complex logic than this with less verbosity, but it naturally provides ways to test other behaviors of Reactive streams such as subscriptions, errors, completions, etc. We’ll only be covering a few. So, let’s see the reactive version of the above test. attendeeRepository.getByAttendeeName("John Wick") .firstElement() .test() .assertNoErrors() .assertValue(attendee -> "John Wick".equals( attendee.getFirstName() + attendee.getLastName() ));   So clean and complete. Just by calling test() on the returned…