Recently I wrote a custom Rx Operator that retries failed http request. The way RxJS allows us to deal with such async problems in just a few lines of code really makes me love this library. But how do we test such operator chains?

Testing async code is hard. To be quite honest, I often need much more time to write unit test for my streams than to implement the productive code itself. I started to ask myself, how can we write test that include async operators like interval, debounce or timer in a more readable and less time consuming way. I finally rolled up my sleeves and did something I wanted to do a long time ago. Introduce marble tests in one of my productive projects.

Marble testing itself isn’t that hard and there are a lot of great resources out there. But I wanted to get an overview of the ecosystem, the TestScheduler and its differences between version 5 and 6. Those topics are less documented and it costed me more time to examine them than expected. This blogpost provides some of the findings I encountered on the way.

TestScheduler as base concept

A scheduler organizes activities in time. Which in RxJS means controlling the event emissions order. In most cases you don’t have to think about Schedulers as the RxJS team has already done that for us. Even though we should know the general purpose of a scheduler and we should also be aware of the possibility to provide a scheduler to an operator. Let’s have a look at the signature of “interval”.