Published in


Small things when unit testing RxJava in Android

Subscribe to the latest blog posts and projects.

Writing always is one of my favorites, it helps me to reorganize information and save it somewhere else outside of my brain. I found it really relaxing, additionally.

A month has passed from my last post about MVP and Android new architecture. Today, I am just going to jot down a small thing about unit testings in which RxJava involves.


If you have a good habit of writing tests whenever adding new features, you are actually confident about your clean and robust codes. If not yet, let’s build that habit from now on. It’s difficult at first (as everything else in life, no doubt), however, you will see a considerably big improvement in your code structure. If you need an introduction to Android Testing, you can take a look at my previous post.


Let’s come back to the main topic. I assume that you have already worked with RxJava and MVP architectural design.

For example, we are building an Android project using MVP architecture. In general, the presenter work is to load data from themodel and show it on theview. Usually, when using RxJava in Android, we fetch and process data asynchronously in a specific scheduler and update or render UI behavior on the UI scheduler (main thread).

We get started with a presenter that looks like the following.

Besides, another important task is to write a unit test to make sure loadItems method runs correctly as expected.

We hope to see friendly “Mr. Green”, but “Mr. Red” comes out with errors. One of the reasons is that our unit test which runs on our local JVM but it triggers our codes requiring Android environment scheduler (AndroidSchedulers.mainThread()), and another scheduler (Schedulers.newThread()) that we do not have the direct control.

The solution is that we need to mock these schedulers too in addition to view and model. Fortunately, in RxJava2, there is a special schedule in the purpose of testing, TestScheduler.

Our unit test is now updated.

Obviously, we need to update the presenter too.

Besides, we are mocking model , so there is no real interaction with the real data stream, so subscribe the method will not work properly as in a real environment. When unit testing, we need to call a method to trigger our test scheduler, testScheduler.triggerActions() . Finally, our test codes look like below.

In summary, when writing tests to cover a piece of our codes that are using RxJava, just go through simple steps.

  • Make sure that our codes are designed to initiate Schedulers from outside.
  • Create Schedulers mock using RxJava TestScheduler in unit tests.
  • Trigger that TestScheduler to drive function behavior as you expect.

It is obviously so simple as you saw. One important thing here is that after refactoring our codes to apply unit testing, its design has been improved. If we continue to cover all of our codes by tests, we definitely see the significant improvements.

If you are interested in my new blog posts and projects, you can subscribe to my newsletter by clicking the below link.

Subscribe to the latest blog posts and projects.

Or please get in touch with me via Github, Twitter, Facebook, or LinkedIn. Happy coding and have a good time!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store