assertLastValue for RxJava TestObservers

The TestObserver is an RxJava staple for testing.

It allows you to assert values in a stream, in the specific order they were emitted. Here’s a quick code snippet from the movies-usf repository ¹:

@Test
fun onSearchingForMovieBladeRunner_shouldSeeSearchResult() {
    viewModel = MSMainVm(mockApp, mockMovieRepo)
    val viewStateTester = viewModel.viewState.test()

    viewModel.processInput(SearchMovieEvent("blade runner 2049"))

    viewStateTester.assertValueAt(1) {
        assertThat(it.searchedMovieTitle).isEqualTo("Searching Movie...")
        true
    }

    viewStateTester.assertValueAt(2) {
        assertThat(it.searchedMovieTitle).isEqualTo("Blade Runner 2049")
        // ...
        true
    }
}

If you look at the source for the base TestObserver, there are a bunch of these useful methods:

Rx Is Coming

i spent a huge part of my 2014 on “Rx” (or reactive extensions) which is essentially a library that helps with a development pattern called “reactive programming”. i think Rx is going to be huge in the app development world. it’s already picked up a lot of steam, but i think it’s going to become a staple for professional app developers.

consider this extremely common scenario:

you’re in Burundi surfing facebook. you want to get the latest updates from facebook, so your smart phone (from a network in Burundi) shoots a request to the facebook servers in Menlo Park. that server reconciles your request and sends back 5 epic selfies from your dearest friends. in our universe, this takes time. maybe not a whole lot according to you (a second perhaps) but for that mini super-computer you hold in your hand, that’s 1000000 microseconds. that’s a long time that you’re asking it to twiddle its thumbs (given that it usually processes stuff in a couple of microseconds). what’s it supposed to do until it hears back from the facebook servers? after it’s done showing you the updates for your first screen, when would it know to trigger another update? what if the data that came back from the servers indicated that you need some more information? what if the third request in that chain failed for some reason? welcome to the world of asynchronous programming. Rx (or FRP as it is mistakingly assumed to be synonymous with) was built to deal with a lot of this pain.

RxJava Tip for the Day - Share, Publish, Refcount and All That Jazz

Ok, so in my previous post I innocuously introduced the .share() operator.

Observable<Object> tapEventEmitter = _rxBus.toObserverable().share();

The .share() operator is basically just a wrapper to the chained call .publish().refcount().

You’ll find the chained combo .publish().refcount() used in quite a few Rx examples on the web. It allows you to “share” the emission of the stream. Considering how powerpacked and frequently used this combo is, RxJava basically introduced the friendlier more useful operator share(). This mechanism is sometimes referred to as “multicasting”.

#2019

#2017

#2016

#2015

#2014