在设计任何系统时，您需要保证操作的正确性，并且随着系统在其整个生命周期内进行修改，此质量不会消退。您将设计测试，理想情况下，测试应该是自动化的。现代软件由彻底的单元测试支持，Rx代码应该没有什么不同。
在单元测试中，我们一般会预定义一些序列值来验证，但是对于异步代码呢？比如下面的代码
Observable.interval(1, TimeUnit.SECONDS).take(5)
这是一个需要5秒钟才能完成的序列。这意味着使用此序列的每个测试都需要5秒或更长时间。如果您要运行数千个测试，这根本不方便。
TestScheduler
上面的代码不仅耗费时间，而且在等待时实际上浪费了所有的时间。如果您可以快进时钟，那么几乎可以立即评估该序列。您实际上无法快进系统的时钟，但您可以快进虚拟时钟。在Rx中，设计决定只通过调度程序使用时间。此决定允许您使用称为TestScheduler的虚拟化时间的调度程序替换。
TestScheduler的调度方式与我们在[Scheduling and threading]一章中所见的调度程序相同(/Part 4 - Concurrency/1. Scheduling and threading.md)）。它会安排立即或将来执行的操作。不同之处在于时间被冻结，只能根据要求进行。我们决定时间进展和多少。
advanceTimeTo
顾名思义，advanceTimeTo将执行计划到特定时刻的所有操作。这包括在调度程序被快进时调度的动作，即由其他动作调度的动作。
输出：
我们安排了3个任务：一个是立即执行，另外两个是将来执行。调度程序将按计划的时间顺序同步执行在该段时间内安排的所有任务。
advanceTimeTo允许您将时间设置为任何值，包括当前时间之前的值。此实现决策可能会在测试中不必要地引入bug，因此在适用时最好使用下一个方法。
advanceTimeBy
advanceTimeBy提前相对于当前时刻的时间。在其他方面，像advanceTimeTo一样。
输出：
triggerActions
triggerActions不提前时间。它只执行计划到目前为止执行的操作。
输出：
Scheduling collisions
没有什么能阻止在同一时刻并发执行。当发生这种情况时，我们会发生scheduling冲突。执行两个同时执行任务的顺序与调度它们的顺序相同。
输出：
Testing
涉及异步操作的Rx operators使用scheduler调度这些操作。如果您查看Observable中的所有运算符，您将看到此类运算符具有scheduler的重载。这是您可以为TestScheduler补充实时调度程序的方法。
下面是一个示例，我们将测试Observable.interval的输出与我们期望它发出的内容。
输出：
这对于测试小的Rx代码片段（例如自定义运算符）非常有用。一个完整的系统可能会单独使用schedulers，从而使我们的虚拟时间失效。Lee Campbell建议使用我们自己的提供商来抽象Rx的调度工厂（Schedulers）。在调试模式下，我们的自定义调度程序工厂将使用TestScheduler替换所有调度程序，然后我们将使用它来控制整个系统的时间。
TestSubscriber
在上面的测试中，我们手动收集了发出的值，并将它们与我们的预期进行了比较。这个过程在测试中很常见，Rx与TestSubscriber一起打包，这将为我们做到这一点。其事件处理程序将收集收到的每个通知，并使它们可供我们检查。使用TestSubscriber，我们之前的测试成为：
输出：
TestSubscriber收集的不仅仅是值，而是通过以下方法露出它们：
这里有两件事需要注意。首先是getLastSeenThread方法。TestSubscriber检查什么线程被唤起并且记录最新的。例如，如果要验证GUI线程上是否执行了操作，那么这将非常有用。另一个有趣的事情是，可能会有多个终止事件，这违背了我们在本指南开头时定义序列的方式。这也是subscriber能够收集多个终止事件的原因。
TestSubscriber为一些基本断言：
还有一种方法可以阻止执行，直到TestSubscriber订阅的observable终止。
如果observable未能按时完成，则等待超时将抛出异常。
原文：https://github.com/Froussios/Intro-To-RxJava/blob/master/Part%204%20-%20Concurrency/2.%20Testing%20Rx.md