对于 PHP 的代码，我们写了非常多的基于 PHPUnit 测试框架的测试类，这些测试类覆盖范围比较大，从简单的判读真假的单元测试到大规模的后端服务的集成测试。开发人员把运行这些基于 PHPUnit 的测试用例作为他们工作中的一部分，同时这些用例也在一些专用的设备上不停地被运行（注：持续集成模式）。当开发人员对一些代码做了比较大的修改时，在开发机器上的自动化工具会运行这些测试用例的同时也会生成相应的代码覆盖率数据，对于需要提交到代码库的 diff，在做代码 review 的时候回自动地产生一份带有覆盖率的测试报告。
　　对于前端的代码，我们使用 Waitir（注：Waitir 是前端 UI 的自动化测试框架）做了基于浏览器的界面自动化测试。这些测试用例涵盖了网站页面的功能，特别是针对隐私方面，比如：“用户X发布了Y，而Y应该/不应该被用户Z看到”，有着大量的基于浏览器级别的这种用例。（这些隐私规则当然也会使用一些更低级别的方法被测试到，但是这些规则的实现是必须要严格执行的，并有着非常高的优先级，因此这部分必须要有足够的测试用例来覆盖）
　　除了一些使用 watir 的全自动化用例以外，我们也有一些半自动化的测试。这些测试也使用了 waitir 技术，这样可以使一些表格填充或者点击 button 来完成整改界面上的流程的测试不太单调乏味，而且我们可以很清楚地检查和验证当前的步骤或流程是否正确合理。
　　我们也在尝试开始使用 JSSpec （注：JavaScript 单元测试框架）去做一些 JavaScript 代码的单元测试，但当前也是刚刚开始做。
　　对于后端服务的测试，根据不同的服务特性我们采用了许多不同的测试框架与方法。对于一些需要开源发布的项目，我们会使用开源的测试框架，像 Boost 和 JUnit 测试框架（注：Boost 是针对C++/JUnit 是针对 Java 的测试框架）；对于另外一些项目，可能永远都不会发布到外界，我们就是使用内部开发的可以很紧密地与我们 build 系统集成在一起的 C++ 测试框架。还有少数项目会使用项目级别的测试工具。多数后端服务的测试都会紧紧地和持续集成/Build 系统结合在一起，这些持续集成的 build 系统会不停地针对源代码自动地运行测试用例并生成测试结果，测试结果在存储在数据库的同时会发送到通知系统中去。
　　HipHop (注：HipHop for PHP 是 Facebook 的 PHP 项目)有一套类似的持续集成系统，HipHop 的单元测试和所有基于 PHPUnit 的测试都会被运行。所有的这些测试结果会和基于普通的 PHP 解释器的结果做对比，从而可以看到不同 PHP 上的行为的不同；
　　Facebook 的测试工具将测试结果存储在数据库的同时会发送一份通知邮件，这个邮件会包含执行失败的信息并且邮件的接收范围是开发同学可以自己调整的。（例如，你可以选择只有在测试连续失败一段时候的时候才接收到通知邮件，或者当一个用力失败的时候立刻收到通知）。在浏览器 UI 上，测试结果和缺陷/开发任务跟踪系统会结合在一起，可以很容易的将测试失败与开发任务关联起来。
　　测试中一个非常重要的现象是“导致阻塞”，也就是一个测试用例失败有可能会阻止发布（在 Facebook，有发布工程师会来评估是否可以将带有问题的代码发布到生产环境，发布工程师在必要的情况下会得到授权去阻止产品的发布）。阻止产品发布上线的事情是被认为是非常严重的问题，因为在 Facebook 大家对于这种快速发布的模式是深深引以为豪的。
　　我所在的团队是测试工程部门，主要职责是打造通用基础工具，这些工具会被上述的所有人用到，同时我们也在维护测试框架，像 PHPUnit 和 Watir。Facebook 没有专职的测试团队，所有的工程师都需要为他们的代码写自动化测试用例，并维护这些测试用例，保证产品代码改变的同时这些测试代码可以正确地运行。
　　Facebook 的测试还处于一个初期起步尝试阶段，上面的介绍都只是我们在当前运行的方法而已。