允许开发者快速开发新特性的原型设计、测试和迭代，对于 Facebook 的成功至关重要。要想有效地实现这一点，关键是要有一个稳定的基础设施，并且不会带来不必要的摩擦。如果相关的基础设施还必须扩大，以支持全球 30 多亿人口，利用日益增长的算力，以及应对一个极其庞大且不断增长的代码库，那么这一点显然更加具有挑战性。
解决这个问题的两种方式是更好的抽象和自动化测试。抽象包含了面向服务的基础设施，它允许业务逻辑结构变成独立编写、部署和扩展组件。尽管这对于快速迭代非常重要，但是也增加了测试的复杂性。在检查服务中的逻辑时，单元测试是有用的，但是无法测试服务间的依赖关系。集成测试可以起到拯救作用，但是，相对标准化的单元测试框架来说，没有现成的集成测试框架可供我们用于后端服务。所以我们设计并构建了这个。
测试输入
通常来说，测试输入是以测试工具的方式提供的，它是一个在测试环境中与测试服务一起执行的程序。一个测试工具可以直接执行服务，也可以通过远程调用（RPC），或者在测试环境中间接执行更改。举例来说，它可以应用新的全局配置设置或者关闭测试服务的副本，尽管测试框架为这些操作提供了原语，但是构建测试由服务所有者负责。
在集成测试中，模板是另一种输入源。可将其配置为发送特定的响应，从根本上作为被测服务的输入。依赖失败代表输入的一种特殊情况，可以通过抛出模拟中的异常来模拟。
测试 Oracle
大多数测试 Oracle 都是针对服务行为的自定义断言。尽管这些断言原则上和单元测试断言类似，但是它们只能检查被测服务的外部可见行为，而非内部状态。它包括 RPC 响应、传递到模拟调用的参数、写入到短暂的测试数据库的数据以及其他示例。
测试基础设施还可以检测常见的错误，比如崩溃或由消毒器标记的 bug，以及被监控基础设施标记的服务健康问题。
可扩展性
集成测试基础设施的设计目标之一就是让团队能够在其之上构建扩展。对于这个扩展，我们主要有两种用途。首先要解决团队服务中心出现的常见模式，例如测试环境设置或者经常使用的自定义。它们还可以为特定类型的测试定义基础，例如灾难准备测试。在需要时，这些测试验证了我们能够从头启动最基本的基础设施服务。比如 ZooKeeper。
