當我開始做 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.
