3. 多 master 之间的二段提交
这是分布式容错的一个经典做法。用 test harness 能把 primary master 和 secondary masters 单独拎出来测试。在测试 primary master 的时候，test harness 扮演 name service 和 secondary masters。在测试 secondary master 的时候，test harness 扮演 name service、primary master、其他 secondary masters。可以比较容易地测试各种 failure 情况。如果不这么做，而直接部署多个 masters 来测试，恐怕很难做到自动化测试。
4. paxos 的实现
Paxos 协议的实现肯定离不了单元测试，因为涉及多个角色中比较复杂的状态变迁。同时，如果我要写 paxos 实现，那么 test harness 也是少不了的，它能自动测试 paxos 节点在真实网络环境下的表现，并且轻易模拟各种 failure 场景。
局限性
如果被测程序有 TCP 之外的 IO，或者其 TCP 协议不易模拟（比如通过 TCP 连接数据库），那么这种测试方案会受到干扰。
对于数据库，如果被测程序只是简单的从数据库 select 一些配置信息，那么或许可以在 test harness 里内嵌一个 in-memory H2 DB engine，然后让被测程序从这里读取数据。当然，前提是被测程序的 DB driver 能连上 H2 （或许不是大问题，H2 支持 JDBC 和 部分 ODBC）。如果被测程序有比较复杂的 SQL 代码，那么 H2 表现的行为不一定和生产环境的数据库一致，这时候恐怕还是要部署测试数据库（有可能为每个开发人员部署一个小的测试数据库，以免相互干扰）。
如果被测程序有其他 IO （写 log 不算），比如 DataNode 会访问文件系统，那么 test harness 没有能把 DataNode 完整地包裹起来，有些 failure cases 不是那么容易测试。这是或许可以把 DataNode 指向 tmpfs，这样能比较容易测试磁盘满的情况。当然，这样也有局限性，因为 tmpfs 没有真实磁盘那么大，也不能模拟磁盘读写错误。我不是分布式存储方面的专家，这些问题留给分布式文件系统的实现者去考虑吧。（测试 paxos 节点似乎也可以用 tmpfs 来模拟 persist storage，由 test case 填充所需的初始数据。）
其他用处
Test harness 除了实现 features 的回归测试，它还有别的用处。
● 加速开发，提高生产力。
前面提到，如果有个新功能（增加一种新的 request type）需要改动两个程序，有可能造成相互等待：客户程序 A 说要先等服务程序 B 实现对应的功能响应，这样 A 才能发送新的请求，不然每次请求就会被拒绝，无法测试；服务程序 B 说要先等 A 能够发送新的请求，这样自己才能开始编码与测试，不然都不知道请求长什么样子，也触发不了新写的代码。（当然，这是我虚构的例子。）
如果 A 和 B 都有各自的 test harness，事情就好办了，双方大致商量一个协议格式，然后分头编码。程序 A 的作者在自己的 harness 里边添加一个 test case，模拟他认为 B 应有的响应，这个响应可以 hard code 某种最常见的响应，不必真的实现所需的判断逻辑（毕竟这是程序 B 的作者该干的事情），然后程序 A 的作者就可以编码并测试自己的程序了。同理，程序 B 的作者也不用等 A 拿出一个半成品来发送新请求，他往自己的 harness 添加一个 test case，模拟他认为 A 应该发送的请求，然后就可以编码并测试自己的新功能。双方齐头并进，减少扯皮。等功能实现得差不多了，两个程序互相连一连，如果发现协议有不一致，检查一下 harness 中的新 test cases（这代表了 A/B 程序对对方的预期），看看那边改动比较方便，很快就能解决问题。
● 压力测试。
Test harness 稍作改进还可以变功能测试为压力测试，供程序员 profiling 用。比如反复不间断发送请求，向被测程序加压。不过，如果被测程序是 C++ 写的，而 test harness 是 Java 写的，有可能出现 test harness 占 100% CPU，而被测程序还跑得优哉游哉的情况。这时候可以单独用 C++ 写一个负载生成器。
小结
以单独的进程作为 test harness 对于开发分布式程序相当有帮助，它能达到单元测试的自动化程度和细致程度，又避免了单元测试对功能代码结构的侵入与依赖。
