RxAndroid overriding schedulers

Rx1TestBase.java

import org.junit.After;
import org.junit.Before;
import rx.Scheduler;
import rx.android.plugins.RxAndroidPlugins;
import rx.android.plugins.RxAndroidSchedulersHook;
import rx.schedulers.Schedulers;

/**
 * JUnit Tests.
 *
 * @author <a href="mailto:[email protected]">Jared Burrows</a>
 */
public abstract class Rx1TestBase {
  @Before public void setUp() throws Exception {
    RxAndroidPlugins.getInstance().registerSchedulersHook(new RxAndroidSchedulersHook() {
      @Override public Scheduler getMainThreadScheduler() {
        return Schedulers.immediate();
      }
    });
  }

  @After public void tearDown() throws Exception {
    RxAndroidPlugins.getInstance().reset();
  }
}

Rx2TestBase.java

import io.reactivex.Scheduler;
import io.reactivex.android.plugins.RxAndroidPlugins;
import io.reactivex.functions.Function;
import io.reactivex.schedulers.Schedulers;
import org.junit.After;
import org.junit.Before;

import java.util.concurrent.Callable;

/**
 * JUnit Tests.
 *
 * @author <a href="mailto:[email protected]">Jared Burrows</a>
 */
public abstract class Rx2TestBase {
  @Before public void setUp() throws Exception {
    RxAndroidPlugins.setInitMainThreadSchedulerHandler(new Function<Callable<Scheduler>, Scheduler>() {
      @Override public Scheduler apply(Callable<Scheduler> schedulerCallable) throws Exception {
        return Schedulers.trampoline();
      }
    });
  }

  @After public void tearDown() throws Exception {
    RxAndroidPlugins.reset();
  }
}

The setInitMainThreadSchedulerHandler call only needs to be made once, so could moved into the @BeforeClass static method (see https://github.com/peter-tackage/rxjava2-scheduler-examples/blob/master/main-thread-example/app/src/test/java/com/petertackage/rxjava2scheduling/MainPresenterTest.java).

As mentioned elsewhere, for the flexibility of composition, these overrides could be moved to @Rule and @ClassRule.

@peter-tackage Thanks! Updated.

I still think that there's an issue, if you only call setInitMainThreadSchedulerHandler in your @Before you still risk of AndroidSchedulers being statically initialized with the Looper dependent Scheduler, which if you are running on the JVM, will thrown an Exception. It's best to call setInitMainThreadSchedulerHandler as early as you possibly can, so in @Before is typically too late, best to move it to either a test runner or in the static @BeforeClass.

Once the baseline Scheduler defined by setInitMainThreadSchedulerHandler has been evaluated, it can't be changed, so there's no benefit/need to call it in each test's @Before hook.

These gotchas are what's lead me to believe that using the plugins should only be done as a last resort.