# Unit Tests and Concurrency

DevFeed: [Unit Tests and Concurrency](<https://devfeed.tech/articles/unit-tests-and-concurrency-25874.md>)

Original publisher: [Read original article](<http://lordraydenmk.github.io//2021/unit-tests-and-concurrency/>)

Author: Stojan Anastasov

Published: 2021-01-06T00:00:00Z

Content type: tutorial

Language: en

Sources: [Stojan Anastasov's blog](<https://devfeed.tech/sources/stojan-anastasov-s-blog.md>)

Topics: [RxJava](<https://devfeed.tech/topics/rxjava.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Android](<https://devfeed.tech/topics/android.md>), [Testing](<https://devfeed.tech/topics/testing.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [api](<https://devfeed.tech/tags/api.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [junit](<https://devfeed.tech/tags/junit.md>), [observeon](<https://devfeed.tech/tags/observeon.md>), [recyclerview](<https://devfeed.tech/tags/recyclerview.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [scheduler](<https://devfeed.tech/tags/scheduler.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [trampoline](<https://devfeed.tech/tags/trampoline.md>)

## AI overview

This tutorial explains how replacing RxJava schedulers with a single test scheduler can hide concurrency problems. It presents an Android example involving concurrent API calls and discusses refactoring the RxJava chain to update the UI as results become available.

## Source excerpt

Once Retrofit added RxJava support, RxJava became my go-to concurrency framework for writing Android apps. One of the great things about RxJava is the excellent testing support. It includes TestObserver, TestScheduler, RxJavaPlugins so you can switch your schedulers in tests. A common approach in testing RxJava code is using a JUnit rule that replaces the Scheduler pools with Schedulers.trampoline() before tests are run and resets them to the original thread pools after the tests. This makes the whole Observable chain runs on a single thread, the same thread the test runs on, which means we can write assertions without worrying about concurrency. However the production code usually is not single threaded. IO operations are done on the IO thread pool, views are updated on the main thread and everything else happens on the computation pool. By using different schedulers in the tests and using a different strategy (single threaded) we make those unit tests useless in catching concurrency issues. A real world scenario I was working on a side project. The screen consists of a RecyclerView displaying a list of elements. To get the elements I need to perform two different API calls. The first API call returns a list with N elements, then for each item in the list I need to perform the second call. After combining the data I send it to the UI for displaying. Using RxJava this looks like: // Emits Loading then Content or Problem private fun requestData(): Observable<ViewState> = service.firstApiCall() .observeOn(Schedulers.computation()) .map { it.message } .flatMap(this::secondApiCall) .map<ViewState> { ViewState.Content(it) } .startWith(Single.just(ViewState.Loading)) .onErrorReturn { ViewState.Problem } .toObservable() // Concurrently executes secondApiCall for each element in list. // Transforms the result to ViewEntity, combines everything in a list private fun secondApiCall(list: List<String>): Single<List<ViewEntity>> = Observable.fromIterable(list) .concatMapEager {