對我們來說，自動化測試幫助開發者編寫更穩定和可靠的代碼。哪怕是一開始對它抱有懷疑態度的開發成員也欣賞它所提供早期反饋的特性，在開發過程中，它也可以更早的 發現Bug。開發者的工作壓力和負荷隨著項目的開展日益加大，盡早的發現和解決Bug也可以避免給開發關鍵時期帶來額外的壓力。
在開發Vision引擎的時候，我們收集了一些數據來研究為提高代碼穩定性而實施自動化測試的有效性。2001年早期，全部依靠人工測試的引擎第一個 release版本開發完成，盡管我們已經進行了很全面的測試，但是每個月，我們的在線技術支持數據庫依然會收到上百個來自客戶的Bug報告。2001年 9月，我們對已有的引擎功能和新增的特征實施自動化測試。這樣，即使我們現在的工作量很大，開發進展也很正常，每月Bug報告的數量銳減（現在大概是5到10個）。
必須強調，這些圖表只是反映了單元測試用例數量和每月Bug數量兩者之間的相互關系，不能將它理解為必然的因果關系。當然，從2001年到2004年，我們在如何編寫健壯的代碼上學到了很多，在這段時間內，開發團隊的人數變動頻頻，但是，這些明顯的差異足以說明穩定性的提升部分歸功于使用了自動化測試。
游戲中自動化測試的局限性
盡管使用自動化測試對于游戲開發來說獲益匪淺，但是也有其局限之處。顯然，很難用它來測試游戲的平衡性，也不太可能用它來測試游戲性和畫面的美觀性。在這幾年里，我們總結了一些編寫自動化測試的要點，重點如下：
*測試最重要的模塊（比如，最復雜和最常用的）。對那些最有可能出問題或者不會破壞原先設計的重構任務進行自動化測試，性價比最高。
*當上層功能性測試難以進行的時候，把精力集中在不同的子系統上。例如，你也許不能通過自動化測試來驗證AI系統是否正常工作，但你可以測試當一個怪獸的體力低于一定數值的時候，它是否會“投降”。
*用壓力測試來驗證你的代碼的強壯性。如果你的游戲在極端條件下運行的很好，比如，每秒有2000個怪獸出生和死亡，一個場景中同時放入500個有真實物理特性的物體，一幅地圖輪流載入200次，那么玩家作一些異常操作時，宕機的可能性就會小很多。
*在修改Bug前，也為它編寫測試用例。這樣的話，可以確保這些Bug在今后的版本中不會重現。
*回歸測試。例如，圖像或狀態比較的話，使用指定的測試場景要比使用產品地圖更容易維護。如果你認為測試用產品數據可能會經常變動，那么你最好使用小的測試場景。否則，不斷的生成新的參考數據會使得開發團隊產生疲倦和厭煩的情緒。
* 測試用例越簡單越好，不要奢望有非常大的覆蓋面。搭建一個易維護和可擴展的自動化測試是一個長期的任務。一般來說，“底層”代碼，例如算術、碰撞檢測和渲染，更容易進行自動化測試，對于游戲性和完整的游戲測試來說，還是需要經過QA人員親自測試。當然，QA部門的注意力也要從技術轉移到與游戲性相關的問題上去�！暗紸房間后，因為通風口前面的箱子太高了，所以出不去”這樣的報告就會取代“當我的角色轉動的時候，屏幕上出現了很多扭曲的三角面”。
持續集成
在一個復雜的軟件項目中引入自動化測試，你會發覺運行它也需要一定的時間，我們看到的一些項目甚至需要幾個小時。如果讓開發者在他們的開發用機上運行的話，測試會完全占用他們的機器，影響工作，那么結果就是他們不去運行測試用例，很顯然，沒有被運行的用例是沒有任何價值的。
解決方法就是搭建一臺或多臺專用的自動化測試機。它同時還運行版本管理軟件（Subversion/CVS/Perforce），一旦發現提交了新代 碼，那么代碼就會被Check out并編譯，測試用例也會自動運行。最后，系統會將測試結果報告以email的形式自動發送給最近提交代碼的開發者。
完全自動化、重復的 build和測試過程，這種過程每天運行多次，在極限編程中，我們把它稱為：持續集成。為了更好的實行持續集成，像 Cruise Control或者Anthill這樣的開源代碼工具可以將版本管理軟件和自動build工具，例如ANT，整合起來。使用這樣的工具， 可以很輕松的搭建適合自己的持續集成系統。
我們發現搭建專用持續集成服務器使得開發過程變得更順暢，開發者可以更專注于自己的工作。與此同時，測試可以被很好的運行，一旦提交了錯誤的代碼，持續集成系統會自動通知開發者和項目經理，因此開發者也可不必為此分心。自動化，自動化！