Home > Tags > Testing

Testing

《修改代碼的藝術》

自從看見書評有關一本名為《修改代碼的藝術》(Working Effectively with Legacy Code, by Michael C. Feathers)的書,感覺是工作上很有需要,就急忙走上 amazon訂了這個內地中譯本。昨天收到並讀了幾章,先說一些表面的,看完後再寫讀後感吧。

如同本書的介紹說:

如果不積極地修改、挽救、隨著時間流逝,所有軟件都會不可避免地漸漸變得複雜、難以理解,最終腐化、變質。因此,理解並修改已經寫好的代碼,是每一位程序員每天都要面對的工作,也是開發程序新特性的基楚。

這些話語都像在對我說的。工作上,每天也要去修改一個很大的 code base,看 source code 好像 reverse-engineering 一樣,看到一些代碼甚至會感到沮喪。或許這也是許多這行業的人的經驗吧,可是我卻是非常缺乏這種經驗,因為以前的我比較多是維護自己設計軟件,比較少去修改別人的軟件。

遺留代碼一般所想就是沒有人維護、時代久遠、甚至是很爛的代碼。但作者對遺留代碼的定義和一般所想的很不同:

對我來說,遺留代碼就是沒有編寫相應測試的代碼。

這不是對遺留代碼字面的解釋,而是一個深切的體會。從樂觀的角度看,這定義引申,遺留代碼並不是無藥可救的東西,只是沒有測試程式而已,只要耐心加入測試機制,就可以慢慢地挽救。

作者提供了一連串的修改程式技術,這些技術沒有正統的名稱,所以每個章節的名稱也很長,例如「第22章 要修改一個巨型方法,郤沒法為它編寫測試」。從目錄看到這章的名稱,又令我回想一個月前用了一整天去理解一個幾千行的函數的遭遇。但是,很諷刺地,在這一部份的最後來一章又叫「第24章 當你感到絕望時」。昨天面對代碼而感到無助時,便立刻看了這一章,頓時覺得,我還未到絕望的境地,心態一轉,難題也解決了。

今天讀到 Fake Object 和 Mock Object,開始明白 Edwin 做的 AMOP 有幾偉大。

要寫漂亮的代碼是以往的一個目標,今天覺得,要寫不變成遺留代碼的代碼,是更重要的。如何在遊戲編程中實踐編寫測試是我今天的疑問 (對於圖像、互動的測試等…..),希望看畢本書後有新的體會,再與大家分享。

Lua 的 Unit Testing

今天成功把 Lua 嵌入Engine (其實只是十數行代碼及設定連結等),之後開了一個新 C++ project 執行一個 Lua 檔案去測試 Engine 提供的介面。

在網上找了一會,選擇了 luaUnit 來做 Unit Testing。luaUnit 的好處是使用 Lua 的 “Reflection” (其實只是找 table 吧),自動找尋所有 test suites。使用起來真的很簡單。以下是我做的 unit test。

Continue reading

Home > Tags > Testing

Search
Feeds
Meta

Return to page top