我對測試的重視是從接觸《測試驅動開發的藝術》這本書開始的,那時我還在做web網站開發。儘管項目沒有對測試做要求,但我還是為自己編寫的service和servlet加上了單元測試,從那以後我一直受益於測試。測試的好處有很多,這裡我總結下我在遊戲開發中使用測試所感受到的最實在的好處。 1、 協同開發時,便於確認到底是誰的錯,自己的,還是別人的。我是負責開發遊戲服務端,項目初期用戶端和服務端都需要編寫網路通訊組件,解析網路資料包。開始我們經常在資料包上遇到問題,用戶端一會說沒收到服務端的資料包,一會說資料解析不正確,是不是服務端加密錯誤了。這個時候就需要一種方式證明我沒錯,是你錯了。一種沒有什麼效果的方法就是複查自己的代碼,但通常查不出什麼錯誤,因為我在審查代碼的時候,心裡會有一種自我暗示,說“My Code不會錯的”,所以很難發現錯誤。查不出錯誤,就會指責是對方錯了,這樣你來我往,慢慢就會發生扯皮的現象。我的方法是,自己類比用戶端發包收包,如果我類比的用戶端可以收到包,我就會讓用戶端程式員來看,他就會認可My Code,重新分析他的代碼。有時候測試發現我類比的用戶端也收不到包或收包錯誤,那麼我就會認識到這很可能是服務端錯了。那麼自己就會換一種心態去審查代碼,這次是“相信自己的代碼有錯誤”,所以會比較容易得發現錯誤。 2、 列出測試清單,驅動開發進程。首先申明,我這裡說的“測試驅動”不是《測試驅動開發的藝術》提倡的方式,我覺得我只能說是“半驅動”。在完成遊戲的攻擊,受擊部分時,我就使用了“半驅動”法。首先先實現基本的技能基礎結構,一邊實現思路也跟著一邊清晰起來,實現後我才開始著手列出測試清單,測試又推動實現的細化。比如考慮受擊過程,我列出如下清單(憑印象寫出):a、 測試受擊方處於不同狀態時,被不同類型的技能命中後,狀態的變化情況b、 測試同時命中多個單位c、 測試一個技能多次命中同一單位,受擊方扣血,狀態的變化情況d、 測試多個技能同時命中同一單位,受擊方的狀態變化情況……開發時,可以以測試為目標,逐個功能去開發,比起這個類擴充完了,再去擴充另一個類的方式要高效的多。我現在開發的方式是,先開發,在編寫測試,然後通過測試再完善開發,是一個不斷迭代的過程。 3、 修改之前設計的代碼,你能通過測試來保證你的修改沒有引入未知的錯誤。有些較基礎的代碼,去修改它,可能會牽一髮而動全身,如果是很早之前寫的代碼,你可能會忘記該具體會影響到哪些地方。這時候,運行一遍測試,就是最好不過的方式了。 題外話:《測試驅動開發的藝術》對我影響較大,對大的影響是讓我開始重視測試,並讓我對測試抱有信心,任何項目都可以引入測試。在維護公司遊戲的時候,我就向部門總監建議過,我們的遊戲要加入單元測試,老大想了想告訴我很難,和我舉了一些實際的例子,說這個功能怎麼怎麼樣,怎麼可能獨立測試呢。如果用公司原來開發的遊戲引擎,確實是不可能做單元測試的。但是當我參與到遊戲開發中時,我始終有這個信念,一定要做單元測試,於是我對引擎做了諸多改良,在設計功能時也會考慮將來如何測試,所以現在我的遊戲引擎是可以支援單元測試的。我想改變來自於信念,首先你要相信自己一定能做到。