当我开始做 WebKit 开发的时候，令我好奇的一件事儿就是这玩艺儿怎么测试。作为一个 Web 开发者，我清楚浏览器渲染引擎有多少 bug （尽管现在情况好了很多），以及日益复杂的web 页面给浏览器引擎带来多大的挑战。伴随bug 一起工作多年自然是要极力避免的事情，所以强制对规范的遵从和避免倒退就显得很关键。
WebKit 的解决方案就是 layout tests。 从最简单层面来说，layout tests 就是提交到 WebKit 源码库中的一堆简单的网页(越简单越好)和期望的渲染结果文件( golden files)，有文本也有图片。测试脚本（ run-webkit-tests）使用一个内嵌了 WebKit 的应用（DumpRenderTree）遍历测试用例（现在有30000多了），然后对比这些测试用例的渲染结果和期望结果(golden
files)，最后将失败、崩溃、超时以及其他和期望不一致的结果生成报告。WebKit 项目中有让 layout test 在已经移植的所有平台上持续运行的编译机，这样就可以容易得发现那些有问题的改动（一旦发现就回滚）。
鼓励开发者在提交代码前先运行 layout tests。最简单的方式是使用 commit queue，它会自动完成测试的执行。如果不这样，在工作站上运行全部测试用例也是可行的，目前运行一遍大约耗时15分钟，如果使用Dirk Pranke 的 multi-process
test runner 时间可以缩短至约 4 分钟或者更少。
通过合理的使用测试数据，layout tests 可以被用来验证很多东西，从 JavaScript 引擎规范一致性到重绘以及 WebSocket 协议的实现。对于类似后者需要访问网络的情况，测试脚本会启动一个本地服务器（Apache, lighthttpd, 或者 WebSocket），然后从服务器上运行测试。本地 HTTP 服务器对模拟网络边界情况也是有用的；让我我觉得很可笑的是，在过去六个月的WebKit 工作中，我被迫学习和使用更多的PHP，比我过去六年做Web开发使用的还要多。
对于比较简单的测试，他们更多采用了单元测试的形式（比如使用断言），有一个辅助的框架可以让这样的测试很容易的搭建起来。对应的期望结果文件里只是一条条的 "success" 描述。
考虑到 layout test 不仅仅测试了渲染、布局，同时也包含了 JavaScript bindings的单元测试，网络堆栈的交互测试，数量级性能测试等等，大家也会偶尔讨论到"layout test" 这个名字越来越不精确。也正是由于这样的灵活性，layout test 模型在引入第三方测试套件的时候也有很好的表现。作为 layout test 的一部分，我们还运行了 Sputnik JavaScript 一致性套件，Philip
Taylor 的 canvas 套件，以及 HTML5 解析套件，和更多其他浏览器厂商的测试用例。
通常情况下，layout test 的执行伴随着所有的代码提交，特别是 fix bug 的代码(保证这个问题不再复现)。这就意味着解决 bug 的第一步是把导致问题出现的网页最简化。如果你提交了一个带有 NeedsReduction 标签的 bug，恰巧你又是触发 bug 网页的作者，那么你就比 WebKit 的开发人员更加适合来创建这个最简化的网页。因为如果一个问题可以归结为重复加载一个页面后查看 alert 或者这个神奇的单词“PASS”，那么调查起来就变得更加容易了。同时如果你提供了一个很好的简化后的测试用例，也意味着你的贡献将永垂不朽，因为这个测试用例每一天都会被运行几百遍。
接下来的一篇会讨论 layout test 系统一些实际的东西，如果要了解更多，请移步 the WebKit wiki.
