Add exhaustive unit test suite to assert the behavior of TestScheduler#triggerActions

[TonyTangAndroid]

This is just an exhaustive unit test to assert the side effects of TestScheduler.triggerActions() applied on TestObserver in different orders.
There are two observedOn and two subscribeOn of TestScheduler. In total, there are 24 combinations on the order when TestScheduler.triggerActions() is executed. And I named it with suffix and subscribe a simple callable with different TestScheduler.

  private final TestScheduler subscribeOn1 = new TestScheduler();
  private final TestScheduler observeOn2 = new TestScheduler();
  private final TestScheduler subscribeOn3 = new TestScheduler();
  private final TestScheduler observeOn4 = new TestScheduler();

  private final TestObserver<Long> interleaved =
      Observable.fromCallable(() -> 1L)
          .subscribeOn(subscribeOn1)
          .observeOn(observeOn2)
          .subscribeOn(subscribeOn3)
          .observeOn(observeOn4)
          .test();

After listing and running all 24 unit test, there are only one correct order, which is 3124, which comes to me as a surprise for two reasons.

• 1, To start with, I do not how to interpret on my own why 3124 is able to receive the item.
• 2, If 3124 is passed, then I would assume that 3142 should also be good. Then to my suprise, 3124 is the only one combination.

Why am I spending my time and countless try on this topic?

TestScheduler indeed comes in handy in asserting RxJava behaviors in a deterministic way until Observable.subscribeOn and Observable.observeOn is introduced. As it is demonstrated in this unit test suite, there are only one way to write the unit test to receive the item for this sample example. And it is mysterious enough. Imagine now we have to write test code to cover the PROD code.

[TonyTangAndroid]

Why is this the only one that receives the item?

[TonyTangAndroid]

Add comments to highlight my confusion.