事情的另一面: 測試與除錯技巧

回顧過去數年的經驗，最大的體悟除《從需求出發理解背後技術的思考脈胳》以及《專注於滿足需求而非工具或方法》之外，大概就是沒有所謂的鐵則，許多事情都有另一面，端看你處於什麼情境、從什麼角度看它。

上份工作以 machine learning 為主 (2008 ~ 2011)，針對一個特定的應用問題，實驗不同的演算法，看看能否實際運用在產品上。結果不如預期時，會陷入不知該懷疑演算法、演算法參數、還是程式寫錯的窘境。因此，對於程式正確的要求，遠高於其它產品。這樣才能專注地藉由實驗修正理論模型。在這個需求之下，Test Driven Development 就成了相當有用的開發方式。經過數次用 TDD 開發的經驗後，總算能夠達到和不用 TDD 差不多的開發效率。這意味著用了 TDD 也不會拖慢完成第一版的時間，並且程式更易於理解和維護。儼然是 TDD 的完全勝利！

但這個經驗有個代價。代價不是學習 TDD 的時間，畢竟學什麼工具或方法 (如OOP) 都要時間。學習 TDD 對立的結果是: 學不到除錯的技巧。

起初我以為除錯是果，治本的方式自然是避免有因。那麼，TDD 貌似完美的解法，學 TDD 即可。但是開發專案免不了團隊合作，也免不了使用第三方程式。換句話說，錯誤遍地都是，有時甚至是作業系統或編譯器的錯。拙劣的除錯技巧無法適應這個時代。我在和別人一起除錯時才發覺這事。對方能力很好，不過開發習慣不太好，常犯一些「我無法想像的錯誤」。但也因為他的習慣，讓他可以比較快看懂別人寫的亂糟糟的程式，可以比較快想到問題可能出錯的地方。我費了不少力氣才補足這塊，實在是始料未及的事。只能說，該走過的路還是得走，無法省去。

目前的工作以 C++ 為主，為了在大量的原始碼裡除錯，偶而會視需求加強一下 gdb 的使用技巧，還有練習寫 python script 簡化 gdb 操作程序。相對於兩年前，gdb 的操作技巧進步不少。另外也寫了 gj 幫助閱讀程式碼。但是在觀察同事的開發方式後，發覺我有時過於依賴工具的便利性，反而減少全面性的思考。最後還是得有系統地一步步思考、推論，才能有效率地解決問題 (關於這點，之後有適當材料再另寫文章說明「系統化的解決問題」)。換句話說，熟練除錯工具反而無意識地減少我系統性思考的時間，也滅少我系統性思考的經驗。我的意思並非捨棄除錯工具，像 Sherlock 那樣全部都在自己的思維宮殿裡解決 (雖說那樣實在是相當地帥啊！)。凡人如我等，還是需要工具輔助搜集情報和記錄訊息。只是這兩件事是相斥的，愈是熟練除錯工具，愈少思考；愈長思考，自然也愈不依賴除錯工具。

再回頭看 TDD，目前的工作絕大多數情況不適用 TDD。一來不像開發 machine learning 工具那樣，要求近乎100%正確。二來大部份的程式和 GUI 相關，本來就不容易測試。若要達到像以前一樣的開發效率，我得先熟悉 C++，再熟悉 C++ 基本的 unit test 工具，再熟悉和 GUI 相關的測試工具和知識。對照達到後帶來的好處，相當地不划算。不過其中一個和 GUI 無關但和網路高度相關的子專案，我很自然地用 Python + TDD 的方式開發核心部份。日後上線時，也從中獲得明確的回報: (1) 極少的錯誤。以及 (2) 透過單元測試輕鬆地重制線上偶而才會發生的網路錯誤，只更新一次程式碼就修正了問題。可參考《寫出容易測試的程式》了解類似的處境和用到的技巧。當然，我也因此「失去」一些線上除錯的經驗。

除了測試與除錯的心得外，軟體設計模式和軟體開發準則，也讓我經歷了幾次「打破鐵則」的心路歷程。之後再另寫文章補充。

回顧這些事，讓我明白個人經驗的侷限，而減少過度歸納和推衍的習慣。看別人的論述時，會多想想自己和對方的情境，從中得出目前我能用到的部份。不會過於尋找或遵從「聖杯」。白話來講，就是比較務實吧。

從需求出發理解背後技術的思考脈胳

最近在技術上多了不少體悟，關鍵是要掌握住問題的需求，接著不斷思考和嘗試，避免卡在特定的規則或工具裡，將重心放在隱藏在這些東西背後的核心思想。

直接看現有的工具或別人的作法很難有所體會，但自己從頭邊做邊想，會得出自己一套理論, 接著會出乎意料地更快理解這些工具和作法。畢竟在足夠嚴苛的需求下，方法可能有些差異，背後的精神卻是類似的。

比方說，若程式反應速度要求在 1ms 以內，全部資料來源都得在記憶體或網路，不能使用硬碟。那麼，針對這種應用，單機程式能做的事只有將東西塞在記憶體裡取用。

然而記憶體有限，資料總有放不進去的時候。在這種速度要求且資料過大的前提下，可能的作法大概是：

• 像 cache 那般有套機制留住最常用的資料。
• 在記憶體裡存 index，index 內存必要的資料，若需要更多資料再從硬碟讀。
• 先做前處理「壓縮」資料成摘要，摘要必須小到可以放入記憶體內。資料的品質(正確性)也許會有一些損失，但是是必要的取捨。之前在讀 YouTube 關聯影片和 IBM 的 Watson 論文時，有看到類似的思路，工作上也做過類似的事。和前述方法不同的地方是，資料的筆數變少，轉為另一種高質量的資料。

再以 Test Driven Development 為例，最重要的不是 TDD 的三步規則，也不是相關工具要怎麼用，而是導入「在設計的開頭, 就將測試視為主要考慮項目」，其它東西都是這個想法的衍生。

從這個角度出發，實作久了自然會理解為什麼介面要開洞放入物件，為什麼需要 factory 隔離生成和操作邏輯。至於是否真的有先寫測試，現在我覺得不是鐵則，在有為測試而考慮的設計下，在必要時補測試可能更划算，將時間花在刀口上。但若一開始沒為測試考慮，事後要補就很辛苦，加測試的價值又更低了。

再往上拉一個層次來看，解決問題的前提，本來就是如何確認問題有被解決，若無法確認問題有無被解決，用什麼方法也是白搭，不知成效如何。從這個角度來看，在設計之初就考慮測試，並不是什麼新穎或強人所難的事。但要走到這步，如同學其它東西一般，需要累積不少經驗。

總結來說，要學習一個技術最好的方法，就是在有適當的需求時再學。平時看到和自己需求無關的知識，加減有個印象在腦裡即可。待要用到時可利用腦裡的索引找出相關資訊，先有個廣泛認知。接著根據自己的需求可以明白那些是比較相關的知識，邊看邊動手做些雛型試試。有了這些操作經驗和背景知識後，再從頭確認一次自己真正的需求為何、有那些限制和對應解法，就能理解要如何應用這些技術和工具到自己的情況裡。

使用 Mockito 更輕鬆地寫 unit test

聽 vgod 提到可以用 PowerMock 來換掉 static、private、final 的方法，還有 Mockito 用起來很順手。於是大概看了一下相關文件:

• PowerMock 的作法是換掉 classloader 和修改 bytecode，所以它可以跨越 Java 的限制 (像是無法換掉 final）。聽起來很威，感覺很危險，不確定是否夠穩定。應該不會想試它。
• Mockito 承接 EasyMock 的思維，但是用起來更容易。雖說它也無法換掉 static、private、final 等方法。

我花了一些時間看了 Mockito 範例和作者設計的思路，覺得很有意思。 《behind the times: Mocks and Stubs aren't Spies》 提到在寫測試碼時，替換掉實際互動的元件，有四種不同層級的輔助元件: dummy、stub、spy、mock：

• dummy: 什麼事也不做。
• stub: 依據輸入傳回物件，藉此控制後續的邏輯。(相對來說) 不在意被呼叫的方式，像是何時被呼叫、呼叫了幾次等。
• spy: 用來確認該物件如何被使用。比方說呼叫 cursor 物件的 commit() 前有沒有先呼叫 execute()。
• mock: 同stub + spy，既需要傳回物件供待測方法使用，也在意它如何被呼叫。

寫測試碼常遇到的困擾是：mock 太囉唆了。這篇提供一個小例子對照 Mockito 和 EasyMock 的差異。《should I worry about the unexpected?》 解釋 mock 之所以囉唆，是因為它管太多了，導致加新功能時，常常行為沒錯，卻無法通過舊的測試。使用 spy (Mockito 的主要功能) 就不會有這種困擾。大多情況我們並不在意是否每一個物件都要如預期般執行，只要關鍵的幾個步驟沒錯即可。

之前會排斥使用 mock 的原因為：

1. 沒有和真正的物件互動，不夠踏實。
2. 寫起來很囉唆。
3. 囉唆就算了，稍微改改程式還很容易出錯。

第一點是 trade-off，有時候是不得不做的必要之惡。在看到 spy 的概念後，發覺它少了後兩項缺點。之後需要用到「mock」時，再來用 Mockito 看看。Mockito 另一個好處是，它有提供各種語言的版本，可以學一套語法走天下。

DRY 的缺點以及測試碼的衝突

這篇是看到 Pylons (Pyramid) 的 《Unit Testing Guidelines》 後寫的心得。

以前我覺得每件事都有標準答案，或是所謂的「Best practice」。後來才發覺這是很嚴重的錯誤認知。因為希望能簡單地處理事情，而一廂情願地認定有「標準答案」，結果忽略了許多反面的訊息。《百人百觀》系列裡道出我的心態轉變。

以 DRY (Don’t Repeat Yourself) 來說，這是資訊人奉為終旨的鐵則，可應用到各種情境。這裡我們先縮小範圍，討論 DRY 對於寫程式的影響。它的優點顯而易見，只需要改一處程式，不會因漏改程式而產生 bug。重覆的程式碼容易造成 bug，複製貼上是常見的主因，甚至有 paper (CP-Miner) 提出方法自動偵測這種 bug。

但是 DRY 的缺點呢？造成 client codes 之間的相依性，迫使所有 client codes 共用同一介面，這帶來不少問題：

• 寫錯共享程式時，影響不止一份程式。
• 最簡單的情境得配合最複雜的情境使用，增加簡單情境的維護成本。即使介面設計的很完善，不需更改呼叫方式，執行時勢必多了一些檢查手續，或在空間上做了些妥協，提高時間和空間的成本，各種 framework 是最好的例子。
• 承上，像 Django 的 session 為了能存各種 object，選擇以 dict 表示 session，直接序列化 session 物件存到資料庫或檔案裡。為了簡化實作並提供無限的空間存 session 資料，用 MySQL 時選擇用 LONGTEXT 以儲存無限制大小的資料，造成每次取資料都要從 disk 讀。在大量使用者連入的時候，這會是個問題。
• 變更一處 client codes 的需求，可能會影響共享程式的介面。選擇相下向容的話，介面會變複雜，可能會多一些選擇性參數。邏輯變複雜，共享程式容易寫錯，client code 使用方式也變複雜。
• 承上，選擇改變介面的話，需找出影響到的 client codes。對 dynamic typing 的語言來說，這是件苦差事，甚至無法 100% 保證沒有遺漏。

如同《Problem Solving 的技巧》裡說的，每個方法都有帶來的好處，也有帶來的壞處，也有針對壞處所做的後續修補。關鍵在於弄清楚現在的需求，明白各項設計的優缺點，配套作出一連串的設計，以獲得整體的最大效益。比方說用 VCS 切 branch 可以減少介面相容問題，不過會多出維護 branch 的成本，那是另一個議題了。

自從意識到 DRY 帶來的成本後，我覺得有些困惑，因為它不再是 100% 正確、用了一定好的原則。在寫測試碼時，我感到更困惑，若測試碼也變複雜，之間有相依性，那誰來保證測試碼是正確的？更何況一個具有完備測試碼的專案，測試碼和產品碼的比例將近 1:1，在量如此大的情況下，測試碼的邏輯太複雜的話，測試碼容易出錯，會造成不少問題。我體驗過測試碼寫太複雜而造成測試碼有錯，因測試碼出錯而誤以為產品碼有錯，結果費了更多力氣才找出錯誤 (程式碼變兩倍)。也體驗過在 setUp 或其它初始化部份出錯，造成訊息混亂，無法掌握錯誤的源頭。後來就不知不覺地將測試碼寫得很簡單，也漸漸減少犯這些錯的機會。

昨天看到 Pylons (Pyramid) 的 《Unit Testing Guidelines》後，才串起過去的經驗，發覺問題的源頭在於 DRY 並不適合用在測試碼，但是 DRY 已成為根深蒂固的習慣，壓根兒就不會想到將重覆程式碼抽出整理成跨 method / class / module 的行為，反而是妨礙測試碼品質的元兇。該篇文章有精闢的說明和例子，推薦大家參考。其中有些規則，現在還不能掌握使用後的優缺點，之後再抽時間讀讀 Pyramid 的原始碼，應該能學到一些東西。

寫出容易測試的程式

昨天和何米特、卡曼德 (不要懷疑，他們都是道地的台灣人）聊到測試，想到一個不錯的例子。這回就用實例來說明「容易測試」和「不容易測試」到底是怎麼一回事。完整的程式可以從這裡取得。

題目說明

從參數列讀入一個網址，計算網頁內的單字數量並輸出到螢幕。單字之間用空白區隔。當網址無效時，輸出 -1。

為了方便說明起見，我選了個簡單但完整的例子。若要將問題變得更有說服力，不妨想像要連線到網頁伺服器，需要來回幾次的通訊和分析網頁內容以達成目的。比方說寫個程式下載漫畫或美女圖之類的。總之，程式愈複雜，下面提到的問題愈嚴重。

直覺的寫法

相信大家看到這題目都會覺得簡單嘛，這樣的程式有什麼難的，寫一寫、跑一跑、改一改，來回幾次就搞定了。寫出來的程式大概長這個樣子：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

import sys import optparse import urllib2   def main(url): '''\ %prog [options] <url> Print the number of words in <url>. Print -1 if <url> is invalid. ''' try: content = urllib2.urlopen(url).read() print sum(len(line.split()) for line in content.split('\n')) except urllib2.URLError, e: print -1   return 0   if __name__ == '__main__': parser = optparse.OptionParser(usage=main.__doc__) options, args = parser.parse_args()   if len(args) != 1: parser.print_help() sys.exit(1)   sys.exit(main(*args))

看起來沒啥問題，但是我們要怎麼確定這份程式是對的？嗯，大概找幾個有效的網址、無效的網址，試一試，看看跑出來的數字對不對。或著專業一點，自己弄幾個簡單的網頁方便計算答案，連入自己的網頁，對看看有沒有算對字數。

可以想見，這個測試過程冗長乏味。之後若做些修改，像是規格改成「輸出的數字要四捨五入到百位」、「輸出全部的字和它的次數」，沒人想從頭重測一次所有情況。

這裡的問題是什麼？問題出在沒有做到自動測試。那就寫個 shell script 讀入一串網址依序執行並存下結果，人工確認結果無誤後，再將答案存起來。之後就執行 shell script 讀網址比對輸出。比方說像這樣：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#!/bin/bash # usage: ./check.sh <prog> function check() { python $1 $2 > t.txt read n < t.txt rm -f t.txt   if [ $n -eq $3 ]; then echo "Pass." else echo "Fail." exit 1 fi }   check MY_PROG http://www.googel.com/ 257 check MY_PROG http://www.googel/ -1

雖然少了冗長的手動測試，上述的測試流程仍有幾個問題：

• 無法保證測試結果一致。有可能連到的網站改變內容，或是剛好連不上，使得每次測試可能得到不同的結果 (即使 Google 不會斷線，它總會改變網頁內容吧)。那麼，測試失敗時，我們怎麼知道是測試過程有問題，還是被測試的程式有問題？
• 測試費時。受到網路連線的限制，測試相當費時。使得我們不會改一小段程式就執行所有測試。若我們能寫一行程式就跑一次測試，馬上能明白是那裡改出問題。
• 測試失敗無法直指錯誤的源頭。我們只知道連 A 網址沒得到預期結果，接著得進程式一步步看，輸出內部資訊才能慢慢找到寫錯的地方。
• 不易準備測試資料。若想測空網頁、有一個字的網頁和有一堆字的網頁，就得準備三個檔案。

目前看來，上述的問題似乎不大。但若有上萬行程式和上百個測試案例，一個案例要跑一秒，加起來就變一百秒。其中又有一兩個偶而會測試失敗，造成每次跑完測試無法相信測試結果。即使測試結果沒有疑慮，當測試失敗時，要怎麼從上萬行程式中找出錯在那裡？

第二版：將計算字元數的部份獨立成函式

在第一版的程式裡，為了測試是否有算對字數，得準備多份網頁和網頁伺服器再透過 HTTP 讀入內文做測試。光看這麼長的描述就會發覺那裡有些不對勁。若將計算字數的部份獨立成一個函式，就能單獨測「無內文」、「只有一個字」、「有很多字」等情況：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

def count_lines(lines): return sum(len(line.split()) for line in lines)   def main(url): '''\ %prog [options] <url> Print the number of words in <url>. Print -1 if <url> is invalid. ''' try: content = urllib2.urlopen(url).read() print count_lines(content.split('\n')) except urllib2.URLError, e: print -1   return 0

獨立出函式後，就能直接測算字數的部份：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

class CountLinesTest(unittest.TestCase): def testEmptyContent(self): actual = wc.count_lines([""]) self.assertEqual(0, actual)   def testAWord(self): actual = wc.count_lines(["camel"]) self.assertEqual(1, actual)   def testWords(self): actual = wc.count_lines(["a camel can fly"]) self.assertEqual(4, actual)   def testWordsWithSpaces(self): actual = wc.count_lines([" a camel can fly "]) self.assertEqual(4, actual)   def testWordsWithAdjacentSpaces(self): actual = wc.count_lines([" a camel can \tfly "]) self.assertEqual(4, actual)   def testMultiLines(self): actual = wc.count_lines(["a", "b c", "d e f"]) self.assertEqual(6, actual)

看來不壞，上面的單元測試可以確保算字數的部份是對的。若上面的測試失敗，也能明白錯在那段程式，又有精簡的輸出入範例協助除錯。並且，獨立出來的函式 (count_lines) 可供其它程式使用。

但是對整個程式來說，我們還是擺脫不了下列問題：

• 無法保證測試結果一致。
• 測試費時。

第三版：將網路連線的部份封裝成物件，並用「傳入」的方式使用它

問題出在 main() 直接用 urllib2.urlopen() 連上網路，若能在測試時替換成我們準備好的函式，就能確保測試結果一致，且減少網路連線的時間。也許有人會說，可以在測試前直接換掉 urllib2.urlopen。這是一個解法，但不建議這麼做，原因日後再說明。比較適當的作法如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

class Client(object): def get(self, url): return urllib2.urlopen(url).read()   def count_web_page(client, url): try: content = client.get(url) except urllib2.URLError, e: return -1 return count_lines(content.split('\n'))   def main(url): '''\ %prog [options] <url> Print the number of words in <url>. Print -1 if <url> is invalid. ''' client = Client() print count_web_page(client, url) return 0

於是我們可以用 mock (我用 pymox) 準備假的 Client 反應出我們期望的網頁連線結果，輕易地測試正常連線和網址無效的情況：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

class CountWebPageTest(unittest.TestCase): def testCountWebPage(self): # Prepare the fixture url = 'http://www.google.com/' client = mox.MockObject(wc.Client) client.get(url).AndReturn('<html> ... </html>') mox.Replay(client)   # Run actual = wc.count_web_page(client, url)   # Verify self.assertEqual(3, actual)   mox.Verify(client)   def testPageNotFound(self): # Prepare the fixture url = 'http://www.google/' client = mox.MockObject(wc.Client) client.get(url).AndRaise(urllib2.URLError("...")) mox.Replay(client)   # Run actual = wc.count_web_page(client, url)   # Verify self.assertEqual(-1, actual)   mox.Verify(client)

回頭看原本的程式有那些改變：

• 獨立出 Client 物件，用來封裝網路連線的操作。
• 傳 client 給 count_web_page() ，而不是在 count_web_page() 內部 new 出 Client。

想想看，若沒有上述兩個改變，要怎麼滿足測試需求呢？該怎麼測試各種網路連線問題呢？這個問題觸及容易測試和不易測試程式的關鍵差異。

結語

就結論來說，一但在函式內直接用全域變數、全域函式或使用自己 new 的物件 X，就不容易測試之後的程式了，因為之後的程式邏輯受到 X 的影響，但測試程式又無法直接控制 X 的行為。當然我們無法完全避免這個情況，總會有全域函式、需要 new 物件。重點在於，我們能將程式隔離到什麼程度？有沒有留「後門」讓測試程式方便控制內部邏輯。

也許有人會懷疑為了測試而改變原本的寫法，是否有些本末倒置？不妨自己練習做個幾次，對照一下原本的寫法和修正後的寫法，用自己的經驗判斷：為測試而改變的結果，是否恰好讓程式變得更彈性、更易重用？

附帶一提，上面的範例碼是逆向寫出來的。我是先用 TDD 寫出最後的版本，再將拆開的東西塞回去 main，弄出「直覺的寫法」。習慣 TDD 後，會改變寫程式的思維。先寫測試有助於寫出易測的程式。

[譯文] 為什麼我們不好意思承認，我們不知道如何寫測試？

原文見：《Why are we embarrassed to admit that we don’t know how to write tests?》。

前言

這篇帶給我很大的影響。對我來說，明白「可測性是最重要的」是一大里程碑。隨著經驗累積，了解得愈深，愈明白 Miško Hevery 寫得多有道理。就當我打算寫篇心得時，才發覺很容易變成用我的話重說 Miško Hevery 說過的東西，而且還很容易漏講。轉念一想，乾脆翻譯他的文章好了。二月底時徵得他的同意，沒想到一拖就拖了一個月半，真不好意思。

大家覺得那裡譯得不好或呈現方式不好，就直接反應出來 。透過 Buzz、Murmur、Plurk、Facebook 或在此留言都可。謝啦。

本文

Take your average developer and ask “do you know language/technology X?” None of us will feel any shame in admitting that we do not know X. After all there are so many languages, frameworks and technologies, how could you know them all? But what if X is writing testable code? Somehow we have trouble answering the question “do you know how to write tests?” Everyone says yes, whether or not we actually know it. It is as if there is some shame in admitting that you don’t know how to write tests.

找出你公司內一般水準的開發者並問他們「你會語言/技術 X嗎？」沒有人會為承認自己不懂 X 而感到不好意思。畢竟有太多程式語言、框架和技術，你怎麼可能全部都會？但若 X 是寫出能被測試的程式呢？不知為何，我們很難回答這個問題：「你會寫測試嗎？」不論我們是否真的懂，每個人都回答會。就如同承認自己不懂寫測試是件很不好意思的事。

Now I am not suggesting that people knowingly lie here, it is just that they think there is nothing to it. We think: I know how to write code, I think my code is pretty good, therefore my code is testable!

我不是暗示人們故意說謊，而是他們認為測試沒什麼大不了的。我們認為「我知道如何寫程式，我覺得我的程式相當不錯，因此程式是可以測試的！」

I personally think that we would do a lot better if we would recognize testability as a skill in its own right. And as such skills are not innate and take years of practice to develop. We could than treat it as any other skill and freely admit that we don’t know it. We could than do something about it. We could offer classes, or other materials to grow our developers, but instead we treat it like breathing. We think that any developer can write testable code.

我個人認為如果我們能意識到可測試性是一個獨立的技術，我們可以做得好多了。這種技術並不是天生就會的，需要經年累月的練習來培養。我們可以將它視為另一項技術並坦率地承認我們不會這項技術。於是我們就能對它做點事。我們能提供課程或其它教材來讓開發者成長，而不是將寫測試的技術視為如同呼吸的能力，好像任何開發者都會寫可以測試的程式。

It took me two years of writing tests first, where I had as much tests as production code, before I started to understand what is the difference between testable and hard to test code. Ask yourself, how long have you been writing tests? What percentage of the code you write is tests?

在我開始了解可測試的程式和難以測試的程式的差別前，我花了兩年的時間先寫測試。在這些程式裡，測試碼的量和產品碼一樣多。問問你自己，你持續寫測試多久了？在你寫的程式裡，測試碼占了百分之多少？

Here is a question which you can ask to prove my point: “How do you write hard to test code?” I like to ask this question in interviews and most of the time I get silence. Sometimes I get people to say, make things private. Well if visibility is your only problem, I have a RegExp for you which will solve all of your problems. The truth is a lot more complicated, the code is hard to test doe to its structure, not doe to its naming conventions or visibility. Do you know the answer?

你可以問這個問題來證明我的觀點：「你如何寫出難以測試的程式？」我喜歡在面試時問這個問題，多數的時候我得到沉默的回應。有時有人回答「隱藏物件」。嗯，如果物件的可見範圍是唯一的問題，我可以給你一個正規表示式讓你解決這問題（譯者注：我猜是在測試程式前先用字串比對把程式內所有 private 換成 public，那就可以測了）。真正的答案複雜許多，是因為程式的結構造成它難以測試，而不是命名習慣或物件的可見範圍。你知道答案嗎？

We all start at the same place. When I first heard about testing I immediately thought about writing a framework which will pretend to be a user so that I can put the app through its paces. It is only natural to thing this way. This kind of tests are called end-to-end-tests (or scenario or large tests), and they should be the last kind of tests which you write not the first thing you think of. End-to-end-tests are great for locating wiring bugs but are pretty bad at locating logical bugs. And most of your mistakes are in logical bugs, those are the hard ones to find. I find it a bit amusing that to fight buggy code we write even more complex framework which will pretends to be the user, so now we have even more code to test.

一開始我們都是一樣的。當我第一次聽到測試時，我立即想到寫一個框架來假裝使用者，使得我能用它來執行被測的應用程式。很自然會這麼想。這類型的測試被稱為使用者端測試（end-to-end-tests）（或是情境測試、大型測試），它們應該是你最後寫的測試，而不是一開始想到的。使用者端測試很適合找出 wiring bugs（譯者注：不知該怎麼翻，請參見 wiring bug 連結的說明），但不適合找出邏輯錯誤。並且，你的多數錯誤會是邏輯錯誤，它們才是難以找到的錯誤。我發覺這有些有趣，為了對抗有錯誤的程式我們卻寫了更複雜的框架來假裝使用者，於是我們有更多程式待測。

Everyone is in search of some magic test framework, technology, the know-how, which will solve the testing woes. Well I have news for you: there is no such thing. The secret in tests is in writing testable code, not in knowing some magic on testing side. And it certainly is not in some company which will sell you some test automation framework. Let me make this super clear: The secret in testing is in writing testable-code! You need to go after your developers not your test-organization.

每個人都在尋找解決測試麻煩的神奇測試框架、技術、知識。然而我有個消息要告訴你：沒有這種東西。測試的祕訣就是寫出能被測試的程式碼，而不是明白測試領域中某種魔法。並且大概不會有某家公司賣你某種自動測試框架。讓我說得更清楚一些：測試的祕訣就是寫出能被測試的程式碼！你需要關注你的開發者而不是你的測試組織。

Now lets think about this. Most organizations have developers which write code and than a test organization to test it. So let me make sure I understand. There is a group of people which write untestable code and a group which desperately tries to put tests around the untestable code. (Oh and test-group is not allowed to change the production code.) The developers are where the mistakes are made, and testers are the ones who feel the pain. Do you think that the developers have any incentive to change their behavior if they don’t feel the pain of their mistakes? Can the test-organization be effective if they can’t change the production code?

現在讓我們想想這點。大部份的組織讓開發者寫程式，接著讓一個測試組織來測試。讓我確保我明白這是怎麼回事，有組人馬寫出無法測試的程式，和另一組人馬分頭試著測試這些無法測試的程式（喔，而且測試小組不被允許改變產品碼）。開發者是錯誤的來源，測試者感受這些痛苦。你認為有任何誘因讓開發者改變他們的行為 — 如果他們沒有為他們製造的錯誤而感到痛苦？在不能改變產品碼的情況下，測試組織能夠有效地作事嗎？

It is so easy to hide behind a “framework” which needs to be built/bought and things will be better. But the root cause is the untestable code, and until we learn to admit that we don’t know how to write testable code, nothing is going to change…

躲在能建造／買來的框架後面是很容易的，事情也會改善。但是問題的根源是無法測試的程式，直到我們學會承認我們不懂如何寫出能被測試的程式，情況不會改變的．．．。

相關閱讀

• Google Tech Talks: The Clean Code Talks — Unit Testing：內容主旨和這篇文章差不多。Miško Hevery 的口語表達很生動，值得一看。
• Top 10 things which make your code hard to test：提及文中問題的答案，值得一讀。

我學 TDD 的方式

學 TDD ( 測試驅動開發 ) 的動機請見《為什麼要寫 unit test？為什麼要先寫測試？》。這篇簡記一下我學習 TDD 的方式：

• TDD 的流程、精神：網路上零散的短文 [1] 和 Kent Beck 的書《Test Driven Development: By Example 》。
• Testing 的技巧：從 Google 的 Agile Coach Miško Hevery 的 Blog 學。
• Refactoring 的技巧：從 Martin Fowler 的書《重構：改善既有程式的設計》以及他的 Blog 學

看完書後，大致上是從大師的 Blog 跳著看有興趣（或著說，讀起來比較有感覺）的部份。自己寫個一陣子就看個幾篇，待思考消化後再回頭試著用自己的方式寫出來。如此反覆進行。最重要的是在自己的環境裡，用自己的方式進行 TDD，感受會更明確。

TDD 的概念很簡單，看過例子後應該能馬上使用，但無法立即精通 TDD 。它是一個習慣，而培養習慣需要時間累積。養成習慣後，接著需要提昇測試和重構的技巧，才能逐步提昇效果並降低使用 TDD 的成本。如同過去學 Design Pattern 或其它寫程式的技巧一般，需要讀書和時間練習。我在前幾次使用 TDD 時有犯一些錯，使得效果打折，有感受到一些好處，但也對一些壞處感到疑惑。直到寫了
五、六個小專案後，才釐清一些疑慮，確信 TDD 是很划算的取捨，從而決定持續使用 TDD。最近用它寫超過一萬行程式，更加感受到它的威力。

備註

1. Java 的例子可見 The Bowling Game Kata；Python 的例子可見 Dive into Python 3 介紹 unittest module 的章節和介紹 refactoring 的章節。《Dive into Python 3》的例子比較不像真實的 TDD，為了教學方便，作者直接寫最終版的測試碼。若要看原汁原味的演化過程，看 Java 的例子或 Kent Beck 的書較適當。

賀！Python 寫破萬行記念！

這是我獨力寫過最大的專案了，從八月初開始寫，不知不覺寫到破萬行啊，而且其中有四千多行是測試碼，貫徹當初 TDD 到底的決心。

不得不說，幸虧有用 TDD，不然測試碼大概會丟三落四的，愈後面會愈痛苦，最後就會想砍掉重練。開發過程裡遇過幾次很難改的情況（第一次發生在寫到兩千多行時），幸好仗著測試碼夠齊全，將相關程式重構後，不知不覺就把新功能寫好了。

有時沒啥想法，不知怎麼改較好，就想說「總之就先重構，船到橋頭自然直」。結果這招矇對的機率還滿高的，有時還會發覺比原本構想更簡單的做法。有些人認為重構成本很高，且短期沒有產值，似乎不適合常做。事實上，在測試碼充沛且時常重構的情況下，可以三兩下完成重構，再加上版本管理系統的輔助，重構失敗立即重來，十分方便。

使用 TDD 偶而會有意外收獲，發覺巧妙設計。有時即使看個數次，還是學不會自己完成目標用上的新技巧，感覺好像用外掛過關，卻不知道自己怎麼過的。最後只能期望下回遇到類似的處理，TDD 仍能導引出良好的設計。對照《物件導向程式的九個體操練習》來看，發現在 TDD 的導引之下，自然地會做出較佳的設計（因為較差的設計不好測），而且會因地制宜，做出貼近需求的做法，不會 overdesign。

雖說在很久以前就確定 TDD 是正確的路，也領悟出可測性 (testability) 是首要之務，為了可測性而改變原本的設計也是合適的決定。還是需要許多實際經驗，才能更充份地體會這些原則帶來的影響。我喜歡 freedom 說過的一句話「 system design 一直都是 trade-off」，經過這一年多的歷練 [1]，我更肯定 TDD 帶來的 trade-off 是值得的，加強寫測試碼的技術絕對是值回票價的投資。

咦？這篇好像離題成行銷 TDD，回頭來補講 Python 的心得。寫這個專案的途中接觸到比較深的 Python 議題，像是用 ctypes 包 C/C++ API 很方便；好用的畫圖函式庫 matplotlib；還有一拖拉庫的速度問題讓我學了不少，比方說：

• cProfile 絕對是找瓶頸的頭號幫手，做 profiling 時也不會拖慢多少。除演算法的考量外，別自己亂猜浪費時間。
• list 很大但不需用到 sublist 或 index 的功能時，可以用 generator 改寫。
• 若有個欄位被存取數百萬次以上，用 data field 會比用 method 快上不少，因為 Python 的 function call 不快。
• collections.defaultdict 比 dict.get(key, default_value) 快上一些。
• CPython 使用 GIL 造成 multi-thread 比 single-thread 還慢，要想用多 CPU 加速，可以用 2.6 內建的 multiprocessing。multiprocessing 用法不難，可是有一堆小細節會爆炸，要仔細讀官方文件。

雖說調速度很辛苦，整體來看還是值得的，而且 Python 和 C/C++ 之間溝通很容易，針對效能改寫的成本不高，更何況有測試碼撐著，修改很容易。讓我覺得用 Python 快速開發原型，針對瓶頸用 C/C++ 改寫或平行化的流程還挺不錯的。

除了以上這堆拉里拉雜的收獲，更大的收獲是學到了一個專案的演化過程。過去自己太心急，什麼都想一開始做到最好，擔心後期會愈來愈難改，災難一發不可收拾。結果是搞得自己很累，開發效率很差、程式品質漸漸變糟也不知道從何改善。後來放開心胸，延伸 TDD 的精神，先做最主要的部份，再慢慢修補小問題：像是註解、模組文件格式、行寛該定多少 [2]、某設計會不會太慢、會不會太髒等。稍微轉換思維、改變自己的習慣，會發現過去許多困擾都不見了，似乎多明白了一點「擁抱變化」的含意了 [3]。

備註

1. 接觸 TDD 的概念；用它實作近十個小專案包含 C++、Java、Python 三種語言；單一專案寫了上萬行的程式。
2. 我後來習慣用 85。這樣用 24″ 螢幕配 putty 預設字型大小，用 VIM 剛好可以垂直分割成兩個視窗而不會折行。
3. 話說我以前一直覺得這個詞很嘴炮啊。

寫 Python 測試碼的好幫手

前陣子用 TDD 寫了個六千多行的工具，這篇記錄一下過程中惠我良多的好幫手。

unittest

內建模組。

用法見官網介紹或《Dive into Python 3》的第九章 Unit Testing ( 有附帶介紹 TDD ) ，如同 Java 的 JUnit 3.x，用 unittest.TestCase 來寫 test case 很方便。

coverage

安裝方式：easy_install coverage。

Code coverage 是分析測試碼品質的方法，標示出測試碼沒有執行到那幾行程式碼。使用 Code coverage 的基本精神是：Code coverage 的數據高不表示測試碼有效，但數據低的話，測試品質必定不好。至於高低要如何界定？這得看專案的類型，比方科學計算型的程式，要求 80% 以上並不過份；而有一堆圖形介面的程式，可能連到 60% 都很難。

coverage 官網有簡單易懂的使用例子。由於 Python 的功能限制，coverage 無法作到像 Java 那麼全面。coverage 的限制以及 Code coverage 的注意事項，詳見作者的說明：“Coverage testing, the good and the bad.”

nose

安裝方式： easy_install nose。

寫 unittest 時，管理 test suit 是件很瑣碎又易犯錯的事，相信很多人會想說，能不能跑個程式，自行搜集目錄下全部的測試碼並自動執行。沒錯，大家的心聲 nose 聽到了！這裡直接用例子說明 nose 的使用方式：

• 執行目前目錄下所有測試：

  1

  nosetests

• 執行目前目錄下所有測試並附上子目錄 pkg1、pkg2 的 Code coverage 資訊：

  1	nosetests --with-coverage --cover-package=pkg1,pkg2 --cover-erase

• 不要執行 slow_test.py：

  1	nosetests -e slow_test.py

• 使用四個 CPU 平行執行測試：

  1	nosetests --processes=4

–with-coverage 需要先裝 coverage；–process 得另裝 package multiprocessing ( easy_install multiprocessing )，相關說明詳見 Multiprocess: parallel testing。

另外，若要讓 nose 跳過物件 A 的測試，就在程式裡寫上

1	A.__test__ = False

比方若不想測模組 mod，就在 mod.py 裡寫上

1	__test__ = False

sqlite3

內建模組。

用法見官網介紹。在測試資料庫時，個人覺得 local database 比 mock 好用，方便準備資料，測起來也比較踏實，而且使用 memory mode 可大幅減少執行時間。附帶一提，sqlite 跨 C、Python、Java 等語言，支援 SQL 92，執行速度又快，相當好用。

PyMox

安裝方式： 用 SVN 從官網 checkout 原始碼，再用 setup.py 安裝：

1 2 3

svn checkout http://pymox.googlecode.com/svn/trunk/ pymox-read-only cd pymox-read-only/ sudo python setup.py install

用法見官網文件。PyMox 是 Google 開發的 Python 版 EasyMock，我試用過 Java 的 EasyMock 後覺得用法挺直覺的，就決定用它，如此一來學一套工具可以同時用在 Java 和 Python 上。使用 mock 的好處是簡化測試碼，更完備地測試程式，像是代換掉處理資料庫、網路連線的物件。如此一來，連測試「讀資料到一半卻斷網」的應對情形，都是輕而易舉的事。若想立即體會 mock 的功效，不妨配合 mock 用 top-down 的方式作 TDD，會發覺不同的程式開發思維。

2012-08-05 更新: 我現在改用 Mockito 了，更為簡單易用 。

驗證第一、想法第二

看到這篇《The Only Truly Failed Project》，其中有兩段話寫得很棒：

Failure is a wonderful teacher. But there’s no need to seek out failure. It will find you.

The only truly failed project is the one where you didn’t learn anything along the way.

最近觀察不少數據和實驗結果，推翻之前許多猜想，不過我沒有像碩士做研究時那般痛苦，反而有些興奮。大概是因為沒有發論文的壓力吧，加上先前讀過費曼的言論，覺得這是理所當然的情況，我們知道得本來就很少，想法通常也是錯的。然而，重點在於如何從錯誤的嘗試中學習？

昨天晚上不斷思索這堆錯誤的嘗試告訴我什麼，仍未有定論。忽然想到愛迪生的話，當他實驗千種材料失敗後，他說，至少我明白這千種材料不能作為燈炮的材料。
於是心裡又更踏實了。但這不表示可以隨意的嘗試，在沒有有效的驗證方式之前，無謂的嘗試無法提供任何訊息。

印象中費曼提過，他不和人討論無法驗證的想法，那是沒有意義的行為。提出猜想後，我會思考如何驗證。直到有辦法進行驗證前，我會先保留想法，改試別的作法。或是將原問題先拆成幾個小問題，讓小問題能夠被驗證。待各個擊破搜集到一些資訊後，再回頭看是否能驗證原本的想法。

能夠驗證的想法，才能從中學習。不然結果出來後，我們無從判斷結果有多接近目標，自然也無法從中學習，進而做修正。舉例來說，如果要做 AI 下棋的搜尋，要怎麼知道目前的策略有效？和人下棋是個辦法，可是沒有無法頻覆進行，也就不能確保方法的可靠程度。另一方面，光看評估盤面函式的輸出值也無用，沒法確認分數高確實是有利的盤面。

換個想法，提兩個策略，互相對戰。至少可以確定每次都贏的策略，是相對來說較好的策略。一個策略可以用 greedy algorithm，另一個用自己想的特別方式。雖然我們預期特別的方法會贏，但若結果相反，也能從中明白新東西：像是 greedy algorithm 比想像中的有效，可從中找到好點子；或是特別的方法不如預期地有效，也就不用再和人下棋，減少後續測試的成本。若擔心兩個方法自動對戰變化有限，可以引用不同棋譜的中盤局面，再引入兩個方法擔任不同角色，觀察好的方法是否在各種相同局面裡，無論擔任那一方，都能下得較好。

再舉解魔術方塊的例子。為了能夠驗證，可以先將解好的盤面一步步弄亂，記下正確的還原步驟和所需步數。準備好多組測試盤面（即最後弄亂的樣子），測試演算法解的效果，步數和預期步數相差多少？那一步發展變得不同？於是有確實的數據可以分析，明白問題出在那。有未知的大進步時（只花了預期的一半步數），也方便觀察出原因（如弄亂盤面時做了不當的重覆操作），不會不小心高估方法的成效。

看起來理所當然的事，沒想到我這麼遲才明白，驗證是如此的重要。而這個觀點卻是從 coding 那邊先萌芽，才接著在研究這邊確實實行。不論是研究還是coding，我認為重要性是: 需求 (動機) > 驗證 > 想法 (解法) > 實作。如《管理是什麼》書裡提到，管理即為客戶創造價值 －－ 相當含糊的定義，可是卻非常精闢。不論是研究還是寫程式，也要先確保能滿足某種需求，之後的發展才有意義。接著，在天馬行空地想解法前，先確保有方法驗證方法的好壞、達到目標的程度、有辦法分析結果，之後才能確實地落實想法。於是，即使失敗仍能有所收獲。

2009-09-06 Update

經 LCamel 一提，發現英文的用詞很有趣，Verification and Validation 裡這麼解釋：

It is sometimes said that validation can be expressed by the query “Are you building the right thing?” and verification by “Are you building the thing right?” “Building the right thing” refers back to the user’s needs, while “building it right” checks that the specifications be correctly implemented by the system.

意即：

• 滿足需求 = validation = do the right thing.
• 驗證作法 = verification = do the thing right.

語言真是奇妙啊，用一句話來總結，就是「Are the do you right thing right?」

為什麼要寫 unit test？為什麼要先寫測試？

這篇說明寫 unit test的好處，以及為何先寫 unit test 再實作，比實作完再補 unit test 更好。這裡先列出摘要：

• 測試碼可以簡省手動測試的時間，但有錯時無法告訴我們錯誤的源頭在那。
• unit test 可以告訴我們錯誤的源頭在那，可是 unit test 有時間成本和維護成本。寫過多 unit test 反而有害。
• TDD 藉由先寫測試避開 unit test 的成本問題，並帶來其它好處。

為什麼要寫測試碼？

吃燒餅那有不掉芝麻，寫程式自然要驗證程式是否正確。想像平時我們如何驗證程式？大概就是寫一寫，執行看看，看看輸出符不符合預期，換些不同輸入，再看看結果，有錯再改，改完再重跑．．．。測試碼可以協助我們自動化驗證，省時省力。

也許有人會懷疑寫測試碼不划算，功能常改變，到時測試碼又要重改。這個問題視情況有不同種解法，比方用較「便宜」的方式寫測試，像是準備好輸出入檔，用 shell script 執行，配合 diff 看輸出是否一致。或是用 scripting language (如 Python) 寫簡單測試。而更根本的解法，個人認為是配合 TDD，待後面說明。

手動執行測試，執行個三十年，每次花的時間還是一樣，也許還會因為手酸變慢。但寫測試碼則相反，我們會愈寫愈快，愈寫功能愈好。

為什麼要寫 unit test (單元測試)？

首先介紹不同級別的測試碼，由小到大依序為：

• unit test：測試對象為單一函式。
• integration test：測試對象為數個單元函式的複合體。我沒特別區分這個和 unit test [*1]，以下兩者一起用 unit test 表示。
• system test：測試整個系統。
• acceptance test：客戶驗收用的測試。將使用情節或使用需求轉成 acceptance test，藉以確認產品滿足客戶要求，方便起見，以下以 system test 統稱。

備註 *1：在談論 mock 時，unit test 和 integration test 的差異較明顯，本文不談這個議題，總得讓大家有意願寫測試，再來談如何寫測試才有意義，你說對吧。

以測試的觀點來看，system test 的 test case 夠多，system test 應該能涵蓋到大範圍的產品碼，如此一來也達成我們一開始提的「驗證」目的。從實務觀點來看，寫愈多測試碼，負擔愈多，規格變動時要改的東西也多。更何況 unit test 著眼點更細，變更實作方式也有可能得改 unit test。如此一來，為什麼要寫 unit test？

首先，unit test 著眼點比 system test 小，也意味著當測試結果不對時，unit test 可以指出更明確的問題點，而 system test 只能粗略地和我們說輸出不對，接著我們得比對正確和錯誤的輸出，開始推測 bug 在那，並用 debugger 設中斷，或在程式內輸出訊息一步步找出問題源頭。相信大家都能明白除錯的痛苦。而 unit test 可以協助我們釐清那些程式是對的，那些是錯的，將問題範圍縮小。若 unit test 寫得好，幾乎用不到 debugger 和輸出訊息，光看那個 unit test 錯誤，就知道 bug 在那。

除了幫自己省時間外，unit test 也可幫助別人維護和理解程式。維護的人不如自己熟悉，難免不小心改爛程式，unit test 可以減少這類問題，也讓原作者安心給其他人修改。新手要閱讀程式時，unit test 可看成是各函式的使用範例，相信大家都同意讀例子比讀全部程式碼來得容易吧。好的範例有時比註解還有用。

為什麼要先寫測試？

好吧，若讀者大人耐著性子看到這裡，想必已對測試碼已有些心動，也認為寫 unit test 有那麼幾分道理，那先寫測試和後寫測試有什麼差別？若後來寫的程式不管用，需求變更，先寫測試不是搬磚砸自己的腳，自找麻煩嗎？事實上正好相反。

我們得先問自己，為什麼程式會不管用？為什麼需求會變更？去除客戶或主管找麻煩的因素外，一部份原因為思慮不週，寫的功能不夠貼近目標。如同產品一般，沒試用過我們不會明白產品的缺點在那，函式也是一樣。先寫測試碼就是先想像要如何使用即將要寫的函式，在寫測試碼的同時，我們同時也在設計函式。有時會發現難以測試，而想出更簡潔的介面。當我們能輕鬆寫出測試碼時，也意味著目標函式易於使用，之後才方便重用。

再者，先寫測試，相當於先列需求，規範中的輸入為何？預期輸出為何？可能有什麼例外情況？於是，我們接著寫出的程式，一定是有用的。我們不會忽然想說「要不要加個 foo()，之後大概會用到吧。」先寫測試，確保之後寫出的每一行產品碼都是有意義的。同時，我們寫的測試碼也是有意義的，若事後再補測試，不明白加入一個 unit test 有何幫助，有時會多寫不必要的 unit test，如同前面提過，測試碼不是萬靈丹，它也同時是負擔，需求變更時，有時也得一併改測試碼。再者，先寫測試表示有先考慮程式的可測性 (testability)，使得程式容易測試，通常會將程式拆得很細，待寫產品碼時容易將寫好的小函式組成目標功能；完成產品碼後再來補測試則困難許多，由於寫產品碼時沒有考慮到寫測試的需求，結果是影響測試碼的品質，甚至變成過於難寫而不補上測試。

除幫助設計、減少寫冗碼的機會外，先寫測試還方便我們之後進行重構。沒有測試碼的重構是很危險的，而沒重構的程式碼也是很危險的 [*2]，就像在底層不穩的地基上不斷加蓋偷工減料的高樓一般。先寫測試的好處還有一點，早寫早享受，先寫測試，就能先自動化驗證，省去所有手動驗證。

備註 *2：為什麼要重構？這是一個值得獨立討論的議題，主因為減少隱藏的 bug 和強化程式碼的可讀性，並更容易重用，以及增加新功能。詳見 Martin Fowler 寫的 《重構：改善既有程式的設計》

綜合以上所言，先寫測試花費的時間，可以攤算在設計時間，以及減少寫無用程式、減少手動驗證、縮短除錯的時間，所以先寫測試不見得會增加額外時間，我們只是把投入不划算事上的時間，先拿來寫測試。

特別加贈：何時該寫新的測試碼？

雖然寫測試好處多多，也別卯起勁來狂寫，最後卻覺得投資沒回本，浪費過多時間寫測試。遵照 TDD 的原則，先依規格寫測試，別浪費時間寫也許有用的測試。

那麼，何時才是跳出 TDD 迴圈，另外加寫測試的時機呢？依我個人經驗，我發現以下三個情況，都是寫新測試碼的好時機：

• 在程式裡輸出訊息找錯誤：與其花時間寫 print、看輸出訊息、再回頭砍掉 print，不如寫個 unit test，之後能持續受惠。
• 執行 debugger：同上，你還是得花時間設中斷，一步步看訊息，不如寫個 unit test，之後能持續受惠。
• 不知錯誤在那，該如何進行下一步：這表示一次貪心實作太多功能，把目標縮小，一步步補 unit test 吧。

另外，在解 bug 時，先寫個 unit test 重製問題，再開始除錯。如此一來可確保自己明白成因，之後同樣的 bug 也不會再出現。

超級加贈：若 TDD 這麼好用，為啥它不遍及？

施主，這個問題得問你自己啊，快來加入推廣 TDD 的行列吧！

說正經的，雖然上面將寫 unit test 和 TDD 說得如此美好，寫 unit test 不是簡單的事。若寫得不好，就會有「改變實作，也得改變測試」的副作用，或是測試執行過久，不方便反覆執行，或是寫出無用的測試。如同學習 design pattern 一般，unit test 也有 design pattern，對沒接觸過寫測試碼的人來說，相當於要花「兩倍」時間學習。加上前面提到大家可能有的誤解，使得 TDD 難以落實。

另一個可能是，若你的組織同時有兩批人馬對同一產品進行開發和除錯，程式碼分成兩個 branch：一個加入新功能，一個除錯。重構會造成程式碼難以合併，決策者因而選擇不頻繁重構。並且，這類組織可能有龐大的人力另外進行測試 (可看成是 system / acceptance test)，而誤以為不需要 unit test。

然而，長遠來看，第一個理由顯然是偷懶，只是把現在的問題延後到日後再解決。趁早把除錯的時間省下來，投資到 TDD 這積優股吧。第二個情況可能是公司考量，專業分工使得公司容易找人和培訓，我沒在這類公司工作的經驗，不知能如何對應。

詳細的 TDD 風險，可參照 What is the downside to Test Driven Development?。結論是團隊要有熱情學一堆新技術，或是有個經驗老道的開發者帶才適合用 TDD。不過，我個人的觀點是，現實世界的選擇不是非一即零，不是所有程式都能 TDD，若成本過高用 TDD 不划算，那就暫時別花時間學相關技巧，挑軟柿子吃。至少，有用 TDD 的部份就能享受到 TDD 帶來的好處。別因為一些可能想見的問題，而全盤否定使用 TDD。

我對 TDD 充滿熱血，請問如何入門？

好吧，這個標題是我寫來自 high 的。若有興趣的話，可以參考 The Bowling Game Kata 的投影片，由設計保齡球計分程式的小例子，一步步展示 TDD 進行的過程，相信跟著例子走一次必能有所啟發，親身體驗 TDD 如何帶來新設計。若能自己先寫一遍，再來看投影片，感受會更深。或是參閱我之前寫的介紹文：《TDD 推廣：背景知識和簡介》以及《最近用 Python + TDD 心得（與 Java 做對照）》。

寫 Blog 好幫手 TD-Post！

為了方便寫 Blog，寫了個小程式讀 wiki code 產生 WordPress 吃的格式，順便藉機練習 TDD，沒想到寫了十小時才完成。剛好最近在看虎x龍的動畫，就將它命名為TD-Post (Tiger x Dragon Post) 吧。

緣起

換過多家 WordPress 用的編輯器後，我還是找不到滿意的工具。為縮短寫 Blog 的時間，我決定自己做一個。

寫 Blog 最惱人的事有幾點：

1. 得輸入麻煩的 HTML，特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀，改文章時很不方便。
2. 加超鏈結很麻煩，常用的幾個超鏈結，得重附貼多次，像 TDD 我就重貼了許多次。
3. 無法用自己慣用的編輯器。若能用 Vim 寫 Blog，速度必能大增啊！

功能簡介

對我來說，寫 wiki code 相當方便，所以輸入格式決定用 wiki code。但 wiki 格式有許多種，我比較常用的有 PmWiki、DokuWiki、TWiki，其中以 PmWiki 語法最簡單，但原始碼沒後兩者好讀。最後聽從 York 的建議，採用 Trac 的 wiki 格式。選它的主要原因除好讀好寫外，我特別喜歡它 Preformatted Text 的格式，很適合用來貼程式碼。

接著，針對第二點問題，加上自動補超鏈結的功能，只要寫過一次超鏈結，TD-Post 就會自動記下來，自動補上對應的位置。像在這段裡，因為我在第一段已寫過 TD-Post 的位置， TD-Post 的超鏈結都會自動補上。初步估計，以後寫一篇 Blog 至少可以省十分鐘，所以差不多用個六十次．．．這幾天的辛勞就．就回本啦。

程式下載

本程式採 BSD License ( 簡單說就是隨便使用 )，歡迎大家玩玩。雖然沒什麼註解，但我照 TDD 流程寫的，測試碼應該很完整。這裡是一些相關資訊：

• 下載：http://code.google.com/p/td-post/downloads/list
• 程式語言：Python
• 程式碼總行數：682 行
• 測式碼：346 行 ( 主要是準備測試的例子 )
• 非測試碼：336 行
• 實作時間：原本預估兩小時完成，卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突，這部份從開始實作到結束花了三小時才解決。

其它

有原始碼有真相，最後附上本文的原始碼：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

為了方便寫 Blog，寫了個小程式讀 wiki code 產生 [http://wordpress.org/ WordPress] 吃的格式，順便藉機練習 [http://en.wikipedia.org/wiki/Test-driven_development TDD]，沒想到寫了十小時才完成。剛好最近在看[http://zh.wikipedia.org/wiki/虎與龍_(小說) 虎x龍]的動畫，就將它命名為[http://code.google.com/p/td-post/ TD-Post] (Tiger x Dragon Post) 吧。   ==== 緣起 ==== 換過多家 [WordPress] 用的編輯器後，我還是找不到滿意的工具。為縮短寫 Blog 的時間，我決定自己做一個。   寫 Blog 最惱人的事有幾點： 1. 得輸入麻煩的 HTML，特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀，改文章時很不方便。 1. 加超鏈結很麻煩，常用的幾個超鏈結，得重附貼多次，像 [TDD] 我就重貼了許多次。 1. 無法用自己慣用的編輯器。若能用 [http://www.vim.org/ Vim] 寫 Blog，速度必能大增啊！   ==== 功能簡介 ==== 對我來說，寫 wiki code 相當方便，所以輸入格式決定用 wiki code。但 wiki 格式有許多種，我比較常用的有 [http://www.pmwiki.org/ PmWiki]、[http://www.dokuwiki.org/ DokuWiki]、[http://twiki.org/ TWiki]，其中以 [PmWiki] 語法最簡單，但原始碼沒後兩者好讀。最後聽從 York 的建議，採用 [http://trac.edgewall.org/ Trac] 的 [http://trac.edgewall.org/wiki/WikiFormatting wiki 格式]。選它的主要原因除好讀好寫外，我特別喜歡它 Preformatted Text 的格式，很適合用來貼程式碼。   接著，針對第二點問題，加上自動補超鏈結的功能，只要寫過一次超鏈結，[TD-Post] 就會自動記下來，自動補上對應的位置。像在這段裡，因為我在第一段已寫過 [TD-Post] 的位置， [TD-Post] 的超鏈結都會自動補上。初步估計，以後寫一篇 Blog 至少可以省十分鐘，所以差不多用個六十次．．．這幾天的辛勞就．就回本啦。   ==== 程式下載 ==== 本程式採 [http://zh.wikipedia.org/w/index.php?title=BSD许可证&variant=zh-tw BSD License] ( 簡單說就是隨便使用 )，歡迎大家玩玩。雖然沒什麼註解，但我照 [TDD] 流程寫的，測試碼應該很完整。這裡是一些相關資訊： * 下載：http://code.google.com/p/td-post/downloads/list * 程式語言：[http://www.python.org/ Python] * 程式碼總行數：682 行 * 測式碼：346 行 ( 主要是準備測試的例子 ) * 非測試碼：336 行 * 實作時間：原本預估兩小時完成，卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突，這部份從開始實作到結束花了三小時才解決。   ==== 其它 ====   有原始碼有真相，最後附上本文的原始碼：{{{ #!html _QUINE_ }}}   身為資工人，這段原始碼當然也是自動貼上的啦，不過我沒用像 [http://en.wikipedia.org/wiki/Quine_(computing) Quine] 那樣的技巧，只是單純地取代關鍵字。

身為資工人，這段原始碼當然也是自動貼上的啦，不過我沒用像 Quine 那樣的技巧，只是單純地取代關鍵字。

最近用 Python + TDD 心得（與 Java 做對照）

最近又用 Python 寫了些程式，剛好和之前用 Java 進行 TDD 做個對照。

若不知道 TDD 的人，可以先參考這篇，TDD 的概念是依以下三個步驟寫程式 ( 順序相當重要 )：

1. 先寫簡單的單元測試，並執行它。
2. 用最簡單的方法實作需要的功能，讓程式能通過測試。
3. 重構程式，並確保重構後的程式仍能通過測試。

實作部份不需多談，這裡先分別對步驟一「寫測試碼」和步驟三「重構」討論，再分享一般性的一點心得。

寫測試碼

Python 寫起測試碼比 Java 簡單許多，可以輕易地抽換所有既有物件，如 module、function、class、method。下面是一個簡單的抽換 method 的例子：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class MyClass(object): def hello(self, msg): print msg   def new_hello(self, msg): print msg + " (by replaced method)"   obj = MyClass() obj.hello('Testing rocks!') # Testing rocks! mystub = stub.Stub() mystub.replace(MyClass, 'hello', new_hello) obj.hello('Testing rocks!') # Testing rocks! (by replaced method) mystub.restore(MyClass, 'hello') obj.hello('Testing rocks!') # Testing rocks!

註解表示該行輸出結果，其中 Stub 是我寫得一個簡單 class，只有十行多，可以替換和還原物件。可以從 MyClass.hello() 的輸出看出，stub.replace() 後 MyClass.hello() 被換為 new_hello()，stub.restore() 後則換了回來。完整的程式碼請看這裡。

方便抽換物件有什麼好處呢？舉例來說，若 class A 有兩個 method B 和 C，其中 B 用到 C ( B 會視 C 傳回結果改變程式流程 )。為了方便測試 B 的行為，得先控制 C 的傳回結果。若是 Python 的話，照上面的例子透過 Stub ( setattr() ) 替換 A.C 即可。但在 Java 的情況，除非將 C 當作參數傳給 B，讓測試程式有機會傳「假的 C 」給 B，不然難以控制 B 內部行為。寫新程式時還有機會改設計，對於舊的程式，修改程式是個災難。用到別人的函式庫或沒程式碼就無解了。不論 Java 有何解法 ( 如採用 injection 的方式 )，解法愈麻煩，表示大眾愈不願意做，因此降低測試碼的品質，連帶影響 TDD 效果。

Mock library 部份，Java 有 EasyMock，Python 有 Mox，兩者用法差不多。後者是前者改來的，學一套兩邊都可以用。

重構

由於 Java 的特性 ( static type )，重構工具相當成熟，我慣用 Eclipse 的重構功能，離開它就不太想寫 Java。其中我最常用的功能是改名稱，包含 variable、method 、 class、 package 等。好的名稱是好程式碼的必要條件之一，好的名稱可以省去冗長的註解、縮短理解程式的時間，同時也有助於作者釐清邏輯，減少犯錯的機會。若發現名稱很難取，也許表示該 object（method / class / package）功能沒規範好，之後容易遇到問題。寫程式難免會犯錯，寫一段時間後才發現命名不夠精確，得回頭修改。若有好的重構工具，改起來快又沒風險，可以提高重構的意願。

反觀 Python 因為 dynamic type，程式碼本身提供的訊息不足（得執行後才清楚全貌），難以透過工具重構。我找了一下相關工具後沒看到滿意的。Eclipse 的 PyDev plugin 有提供重構，但試用後結果是錯的，改 module 名稱時沒動到檔名，執行後才會發現程式碼爛了。另外試了 Rope ，可以正確改名，可是速度有點慢，操作相當不直覺 ( 之後再來試看看 ropevim )。為了長遠發展考量，或許可以試看看自己弄個簡單版的改名工具或改 Rope，工具的功能可以少，但要快、容易操作且結果正確。

結語

只有在三個步驟都確實做到時，TDD 才能發揮應有的威力。依我目前一點點的實作心得，Python 容易寫測試碼、卻不方便重構；而 Java 正好相反。現在我大多有照 TDD 的流程寫程式，即使寫個一小時的小程式，也會用 TDD 。有時寫寫覺得卡卡的，才發現忘了先寫測試碼。

另外，測試碼的範圍抓得準 ( 別測太細，也別懶得測核心) ，效果才會好。我初用 TDD + Python 時就矯枉過正，寫太多測試變成 「over-testing」，省了 over-design 的負擔，卻多花時間寫不必要的測試碼、又增加日後維護的成本 。

養成 TDD 習慣的關鍵，在於寫測試碼的功力，像是如何準備 fixture ，如何改善函式介面以利測試。為了寫測試而改變函式介面並不是本末倒置，通常這會降低函式之間的關聯性，將功能明確切開，讓每個函式的輸入輸出都很乾淨（有簡單的輸入，才方便準備 fixture）。而乾淨的輸入輸出意味著函式更容易被組合使用。

軟體開發技巧的待讀書單

經過這陣子的評估，終於列出了夢幻般 (?) 的讀書清單。我的做法是先在網上看到有人推薦，到書局翻一陣子，再回來查 Amazon 的評論，最後決定是否有必要看。附帶一提，待這書單決定後又查了一下，結果發現每本書都有得到 Jolt Award，一瞬間好像以為 Jolt Award 不值錢了 :-)。

以下依暫定的閱讀順序依序說明，除前兩本外，後三本都有中文版：

1. Test Driven Development by Examples

Amazon 評論 4 顆星，由 Kent Beck 所著。全書只有 200+ 頁，用大量的例子，一步一步說明怎麼進行 TDD，相當易讀。這裡有別人寫的詳細書評。

2. xUnit Test Patterns: Refactoring Test Code

Amazon 評論 4.5 顆星，不過只有七筆評論，樣本略嫌不足。 在書店試翻的感想是：好書但不易讀，而且實在是太厚了。ThoughtWorks 專出這種書嗎？

3. Refactoring to Patterns

Amazon 評論 4 顆星，但評論兩極化落在 3 和 5，最中肯的評論為： "Good ideas, but needs refactoring"，值得一讀，但不好消化。讀過 Martin Fowler 的 Refactoring 並有一段實戰經驗後的最佳書藉。本書中文版《重構－向範式前進》，且是侯捷合譯的 。

4. Head First - Head First Object-Oriented Analysis and Design

Amazon 評論 4 顆星，評論裡指出本書適合初學者，另外最多人同意的評論 (Decent Introduction to OOA&D) 指出：本書不夠簡潔，並有不少小錯，若有第二版才值得推薦。 

5. Head First - Design Pattern

Amazon 評論 4.5 顆星，且是壓倒性的一堆 5 顆星。Head First 的書以易讀出名，但通常也寫得很厚，需要花不少時間消化 。 對照過於精簡典雅的 Design Pattern Bible Book，這本書親切不少。附帶一提，在書店還有看到 Head First - Algebra，真是太有趣了！可惜是教國中代數，不是教線性代數。

依目前心得來說，有四件事要學：

1. 寫出良好的測試程式 - book 2
2. 寫出良好的 OOP- book 4, 5
3. 提昇重構技巧 - book 3
4. TDD (其實就是上述三者的綜合體) - book 1

前往軟體開發聖殿之路是很遠的，希望一個月至少能解決一本，並持續地應用到實戰中，半年後就出師啦！

備註

這裡補充我曾看過且大力推薦的書藉：

• Effective Java Programming Language Guide：Joshua Bloch 所著。中文版只有第一版，但原文已有第二版，我只看過中譯第一版。本書適合偶而拿出來重習學習，薄又易讀。若不認識 Joshua Bloch，至少也應該用過他做的 Java Collections Framework。
• 重構：改善既有程式的設計：Martin Fowler 所著，淺顯易懂的好書。說明何謂壞程式碼，以及如何一小步一小步安全地修正壞程式碼。

TDD 推廣：結語和參考資料

續前篇，這篇說明我和組員近兩週開發過程中的心得，並附上幾篇不錯的參考資料。

結語

目前我和組員只有做到半套的 TDD，有時有照三步驟的順序進行，有時是先寫程式碼，再補測試碼，或兩者交替寫。目前組員有感受到測試程式的好處，例如對程式有信心、避免因修改而破壞既有功能。組員也漸漸感受到重構的必要性。但對於先寫測試碼這點，仍有疑慮而難以進行。至少，我們盡量遵守 TDD 的結果，在寫另一個 class 時，會先補好測試碼，保持程式碼的品質。附帶一提，配合 IDE 的功能，先寫測試碼可以輕鬆地建出產品用程式的框架。像 Eclipse 可以自動產生不存在的 class、method、field，所以我常先寫測試，再用 Eclipse 建出這些東西的殼，之後再填入內容，寫起來相當快。

開發過程也不盡是順利。藉由頻繁的 code review 組員的程式碼，還有回顧自己的程式碼，我發現許多問題。像是單一測試函式太大、測試碼和程式關聯性過高、測試時間過長，若沒有第一時間更正，後果不堪設想，也會使得組員對 TDD 有不當的負面認知。這方面的相關知識可以搜尋 TDD antipattern，或 JUnit antipattern。

此外，由於組員少了前備知識，進行開發過程裡會看到許多 code smell，常常在重構一段程式前，必須先重構另一段程式，而重構另一段程式前，又得先補對應的測試程式或重構測試程式。這才體會到良好品質的程式碼得來不易，需要全組成員一同堅持和維護，大家的相關知識也需要一同逐步提昇，才能達到良好的軟體開發流程。雖然初期摸索很花時間，相信日後會有相當高的回報。

說了這麼多，其實仍抵不過自己親身嘗試，強力建議親身找個小專案，用 TDD 的三個步驟寫個千行程式，相信程式設計思維會有很大的轉換。

參考資料

我到 slideshare 找了一陣子，看到三份不錯的教學，但各有些不足，沒有一份完全符合我預期的入門文件。若有時間的話，自己再來作份投影片。

• Testing In Java：提供簡單清楚的 TDD 流程圖，並附有多個工具連結供日後參考。
• Test Driven Development Tutorial：提供詳細的介紹，包含相關工具的參考。
• Changing Your Mindset: Getting Started With Test-Driven Development：實戰是最容易了解 TDD 的方法，這篇直接展示 TDD 過程中程式碼的變化。若看得懂 Ruby 的話，是很不錯的介紹。

相關閱讀

• TDD 推廣：背景知識和簡介
• TDD 推廣：影響和個案心得
• TDD 推廣：相關工具

TDD 推廣：相關工具

續前篇，這篇說明我近兩週開發過程中選擇工具的心得。

開發環境

我採用 Eclipse，配合 Eclipse 的 refactoring tool，大幅加快重構的速度。人都有惰性，好工具讓我們更願意重構，而且降低重構過程除錯的風險。對照之前我自己寫 C++ 和 Python 的經驗，現在我更常做 rename variable/method、change method signature 之類的操作。

Unit Test

經過評估後，我決定用 JUnix 4.x。JUnit 4.x 改用 annotation 的方式表示 test method，可以去除必須繼承 TestCase 的限制。如此一來 test method 命名彈性更大，而且也可以直接在 class 裡加 test method 測 private method，解決因 private 不方便測試的困擾。不過我不確定這種作法是否正確，仍需多點經驗判斷。其它 JUnix 4.x 的好處可以參照《An early look at JUnit 4》。

關於 unit test 的技巧， ThoughtWorks 有出相關的書：《xUnit Test Patterns: Refactoring Test Cod》。有機會再去書店翻看看。

Mock lib

關於 mock 的知識可以參見 Martin Fowler 的《Mocks Aren’t Stubs》，解釋得鞭闢入理，除介紹 mock 外，更進一步指出用與不用 mock，其實測試思維是截然不同的（確認物件行為或確認物件狀態），有機會的話再對此另寫心得。文中的範例程式有點過時（畢竟是舊文章），現在 mock lib 的用法更方便一些。Java 的 mock lib 有許多選擇，最後我選用 EasyMockZ。除了好用外，主要是因為 Python 的 Mox 是從 EasyMock 來的，這樣寫 Python 時可以花較少心力學 Mox。

2012-08-05 更新: 我現在改用Mockito了，更為簡單易用 。

Database unit testing

若只是用到簡單的 database 操作，可以用 EasyMock 處理，。測試前準備好 mock connection、mock statment、mock resutSet 即可。一方面是初學 mock 的緣故，另一方面也是 database 相關操作太瑣碎，我花了一整個下午才用 EasyMock 完成測試程式並寫好對應的功能。事後修改挺複雜的，比方說我程式裡補了 close()，mock statement/connection 也要記得加。感覺不是理想的作法，這方面經驗尚淺，需要多點實戰。

若要測得更深更全面一些，測試對 DBMS 本身的操作（ insert / delete / update）的話，用 DBUnit 會方便許多。DBUnit 的基本精神是幫測試程式準備好已知狀態的資料庫，以及比對兩個資料庫是否相等。它的核心功能是將資料庫內容和 XML 檔案互轉。所以，先建好一個資料庫，透過 DBUnit 將整個資料庫存成一個 XML 檔，日後隨時都能用該 XML 檔還原回原樣。

對測試程式而言，執行速度是非常重要的，執行速度快才能反覆地執行多次，才方便反覆開發、重構以及整合測試。所以我改用 SQLite 做為測試用的資料庫，真正的產品再用 MySQL 之類的 DBMS。SQLite 的好處是支援 SQL92 的語法，整個資料庫只要一個檔案即可。如此一來只需要讀寫本機檔案，省去網路連線的負擔，也方便建置測試環境。

由於使用 DBUnit 前得先準備好資料庫才行，我得先從既有的 MySQL database 建出同樣 schema 的 SQLite database，才能用 DBUnit 做後續的操作。原本打算寫個程式讀出 MySQL database schema 再建出 SQLite database schema。但兩者建 table 語法差太多，無法直接套用。最後我是利用 DBUnit 產生的 XML 檔，寫程式從 XML 檔中讀出 table 和 column 名稱，再建出簡單的 SQL 指令來建出 SQLite database。如此一來，每次自動測試前我先用 DBUnit 將 SQLite database 填入備好的資料，就能快速地重覆在同樣的狀態下測試資料庫操作的程式碼。待有更多相關經驗後，再針對此議題寫篇心得。

相關閱讀

• TDD 推廣：背景知識和簡介
• TDD 推廣：影響和個案心得
• TDD 推廣：結語和參考資料

TDD 推廣：影響和個案心得

續前篇，這篇談 TDD 帶來的改變，以及我自己的個案心得。

TDD 的影響

只要用 TDD 重寫以前寫過的小專案，就會發現最後的產出，和原本寫的程式不同。舉例來說，會發現少了很多 setter function，因為大多情況只要用 constructor 放值即可。更進一步，會發現少寫了許多功能，而這些功能其實是原本不需用到的。

TDD 同時也幫助設計出易用的介面，透過寫測試程式的過程，可以釐清程式的使用方式。當發現程式不好測試時，通常意味著程式設計不良。測試程式也可以當作文件使用，提供使用程式的範例程式碼。

除此之外，在 TDD 的過程中，開發的速度很順暢，很少會落入長時間的除錯裡，因為程式被強迫切成許多小單位，並且每一單位都有被測試。一但出錯馬上會發現，而且知道錯在那裡。不像以往得用 debugger 追個老半天，最後發現 bug 在很遠的一小段程式碼裡，有時還是簡單的打錯字。在除錯的過程，藉由自動化測試的幫助，修改和執行可以快速地反覆交替進行，減少除錯以外的精神損耗（如手動準備執行需要的資料、設置和操作 debugger ）。即使寫測試程式花的時間和除錯一樣多（我相信會是較少），至少以 TDD 的方式進行，心情會比較愉快，不會卡在一個地方太久。

TDD 的個案心得

以我最近的實作案例來說，我一開始知道會用到數個算數函數，而且這些函數日後需要抽換為不同的算法，方便我比較何種組合效果最好。舉例來說，我需要實作排序演算法 Sort()，由於資料分佈特性的改變，我可能需要實作各種演算法如 quick sort、heap sort、insertion sort、radix sort 等，並讓這些演算法的輸入輸出介面一致，方便視情況抽換不同的演算法。在這個案例裡，我需要寫多個這類型的演算法，把它們整合成一個較大的程式。

若照我原本的習慣，大概就全部套 strategy pattern，於是我可能會先寫數個 interface 或是寫個 abstract class 再套多型。至少會花半天完成這些工作，並且增加一堆「未來可能會用到」的 class。但這回我忍住了，我遵從 TDD 的三個步驟，我先統統用 static method 寫，因為這是最簡單的實作。結果寫個兩天後，我發現這幾個算數函數，其實只有一個真的需要套 strategy pattern，其它用 static method 就夠了。也許那一個最複雜的函數也不需用到 strategy pattern，總之，由於目前仍無需求，我全部都保留原樣。於是我將時間花在刀口上，優先完成必要的事。並且，我的 class space 沒有被一堆「也許有用」的 interface 和 class 汙染，避免 over-design，提高整體的可讀性。

相信大家看到這都會大喊，全部都等用到才寫，日後難道不會付出更大的代價做變動？改程式碼的代價很高，所以應該多費些心力設計好才對吧？但別忘了，「改程式碼的代價很高」是一般的情況，在有充沛的測試程式做為後盾的情況下，改程式的代價其實沒那麼高。況且，程式碼隨時都有重構，程式應該是保持在容易修改的情況，改程式的代價又更低了。

至於初期的設計要精確到什麼程度才開始寫程式，仍需經驗拿捏。我目前的作法是先有個大概的整體設計，再開始用 TDD 的方式實作各個 class，並完成細部的設計。

相關閱讀

• TDD 推廣：背景知識和簡介
• TDD 推廣：相關工具
• TDD 推廣：結語和參考資料

TDD 推廣：背景知識和簡介

之前我曾獨自一人用 TDD (Test Driven Development，中譯為測試驅動開發) 的方式，分別用 Python 和 C++ 各寫了一千多行的小程式，感覺滿好的。最近剛好有機會寫一個新專案，就趁這機會開始第三次的 TDD 練習。和前兩次不同的是，這次要和一位組員合作，以 Java 開發。看來正是測試 TDD 威能的最好時機。

由於我的組員缺乏寫測試程式的經驗，剛好可以用來評估是否能在組內推廣 TDD。雖然我之前有過兩次 TDD 開發經驗，但也只是自己邊看文件邊摸索，經驗仍嫌不足。這次進行 TDD 讓我多花了不少心力查相關資料。但是為了擺脫軟體開發後期的泥沼，現在先下點苦工是值得的。這裡記錄一下過程中的心得。

背景知識

了解 TDD 前，得先知道重構 ( Refactoring ) 和單元測試 ( Unit Testing )。個人大力推薦 Martin Fowler 寫的《重構：改善既有程式的設計 》，可以了解何謂好的程式碼、如何找出該改善的程式碼以及如何改善它。書中列出多種簡單的操作流程，相當淺顯易懂。附帶一提，Martin Fowler 的個人站有許多經典好文，值得細細咀嚼。

TDD 簡介

TDD 是個知難行易的道理。知難，是因為我們很難相信它，到不是因為 TDD 概念很複雜，只要三句話就可以交待完 TDD：

1. 先寫簡單的單元測試，並執行它。
2. 用最簡單的方法實作需要的功能，讓程式能通過測試。
3. 重構程式，並確保重構後的程式仍能通過測試。

實務上，這三條規則蘊含了經年累月的經驗法則。若沒親身體驗過，再怎麼解釋它們帶來的好處，也很難令人信服。這三條規則是環環相扣的，由於有先寫測試，才能安心地重構；由於有重構，才能方便地擴充功能；由於專注於最簡單的實作，省掉 over-design 的時間，才能用更快的速度完成該作的事，並有多餘時間寫測試程式和重構。藉由測試程式，程式設計師可以提高對程式碼的信心；透過重構，程式碼易於修改和重用。注意這裡強調「最簡單」的實作，這正是 TDD 精神所在，簡單的實作易於進行，複雜的考量如程式碼是否能重用、是否易於擴充，都留待第三步再做。專心正是將事做得又快又好的祕訣。

天下沒有白吃的午餐，要做到如上所述的理想世界，必須學許多寫測試程式的技巧。如同平常寫程式有輔助工具、函式庫、設計模式等，測試程式亦有對應的東西要學。舉例來說，產品用的程式需要重構，測試用的程式也需要重構。關鍵在於「treating their tests like first-class citizens. 」。反之若將測試程式視為可有可無的附帶程式，只會陷入惡性循環，改變產品用程式的細節得改變測試用程式，反而變成得改兩倍的程式，以及在兩份程式中除錯。結果變得更糟，並誤認為測試程式是累贅。我剛用 TDD 時就因為沒把測試程式寫成許多小巧的函式，或是沒有寫成正確的檢查方式，造成產品用的程式是對的，卻常在測試程式裡除錯，造成無謂的損耗。

相關閱讀

• TDD 推廣：影響和個案心得
• TDD 推廣：相關工具
• TDD 推廣：結語和參考資料

讓 Python 的 unittestgui 可以載入 test suite

由於 pyUnit 附的 unittestgui 怎麼試都沒成功，我改用這個 unittestgui.py：GUI test runner using wxPython。相關說明請見之前的文章。美中不足的是，它不方便載入 test suite，所以我修改了一下這份程式。

程式下載和用法

點此下載修改後的程式碼。使用的範例程式碼如下：

1 2 3 4 5 6 7 8 9

# all_test_suite.py import unittest import catsinbag.card_factory_test import catsinbag.cash_test   def suite(): suites = [] suites.append(unittest.TestLoader().loadTestsFromTestCase(some_module.SomeTestCase)) return unittest.TestSuite(suites)

執行 unittestgui.py 後，按 Open 選擇 all_test_suite.py 即可載入。

目前這個工具仍有些問題，像是原始碼改過後，得重開檔案載入後才會生效，所以無法一邊改程式碼一邊按 Run Test。還有錯誤訊息顯示得不夠清楚，而且還是顯示在 console 上，不是顯示在 GUI 上。

修改過程心得

參照 unittest官方文件，最方便載入多個 test cases 和 test suites 的方法，是採用下面這段 code：

1 2 3

suite1 = unittest.TestLoader().loadTestsFromTestCase(SomeTestCase1) suite2 = unittest.TestLoader().loadTestsFromTestCase(SomeTestCase2) alltests = unittest.TestSuite([suite1, suite2])

若自己用 console 執行 unittest，只要把 alltests 交給 TextTextRunner 即可，例如：

1	unittest.TextTestRunner(verbosity=2).run(alltests)

但是，一個熱愛寫 testing 程式的程式設計師，除了想要有更高品質的程式碼外，內心更渴望看到 Green Bar啊！所以非得用 GUI 版的 unittest 不可。而 unittestgui.py 可以載入 test case、test suite，卻沒辦法載入 module 內產生的 test suite。所以只好直接改 unittestgui.py 的程式碼。關鍵在於 OnMenuOpen() 如何取得 test suite。原本的程式碼如下：

1 2 3 4 5 6 7

modname, modtype = os.path.splitext(os.path.basename(self.filename)) if modtype.lower() == '.py': moduleToTest = imp.load_source(modname, self.filename, file(self.filename)) elif modtype.lower() in {'.pyc':0, '.pyo':0}: moduleToTest = imp.load_compiled(modname, self.filename, file(self.filename, 'rb')) #print moduleToTest, dir(moduleToTest) self.suite = unittest.defaultTestLoader.loadTestsFromModule(moduleToTest)

修改後的程式碼如下：

1 2 3 4 5 6 7 8 9 10 11 12 13

modname, modtype = os.path.splitext(os.path.basename(self.filename)) if modtype.lower() == '.py': moduleToTest = imp.load_source(modname, self.filename, file(self.filename)) elif modtype.lower() in {'.pyc':0, '.pyo':0}: moduleToTest = imp.load_compiled(modname, self.filename, file(self.filename, 'rb')) #print moduleToTest, dir(moduleToTest) if hasattr(moduleToTest, 'suite'): # use the prepared suite if it exists. if callable(moduleToTest.suite): self.suite = moduleToTest.suite() else: self.suite = moduleToTest.suite else: self.suite = unittest.defaultTestLoader.loadTestsFromModule(moduleToTest)

利用已讀到的 module: moduleToTest，增加判斷它是否有提供 function suite() 或是 attribute suite，若有的話，直接使用準備好的 test suite，而非從 TestCase 或 TestSuite 中產生。

最後附上執行後的精美圖片，辛苦了這麼久，就是為了看到這 Green Bar 啊！

Windows 下初寫 Python 心得

今天下午用了一下 Python 處理簡單的文字檔，結果激起我對 Python 沉封已久的渴望，晚上看個半集動畫後，就試著在 Windows 下寫看看 Python。

除 Java 外，多年來我都習慣在 Unix 下寫程式，用 Windows 時也是透過 putty 連入 Unix，開 screen + vim split 來寫。這次轉念一想，乾脆來試看看在 Windows 下開發的情況，順便增長見聞。

保險起見，我選擇用 Python 2.6 而不是最近剛出來的 Python 3000。安裝時會要求選個路徑，我先開個 D:Python，之後打算把東西都丟在這下面，所以就裝在 D:PythonPython26下。裝好後的第一印象是，Windows 版有精美的 chm 檔真好，索引文件超方便！

再來是設定 VIM：

• 下載 python.vim到 C:Documents and SettingsUSERvimfilesindent ( 需先自行新增目錄 vimfiles 和 vimfilesindent )，並在 C:Documents and SettingsUSER_vimrc 裡加上：

  1	autocmd BufRead,BufNewFile *.py set sw=4 tabstop=4 smarttab smartindent expandtab

  如此一來才能方便地縮排和有漂亮的色彩。

• 為了方便執行，在 _vimrc 裡加上：

  1	autocmd BufRead,BufNewFile *.py map <F10>% w !python<CR>

  這樣就能按 F10 執行目前編輯的 script。

編輯環境弄好後開始試 Test Driven Development ，來看 pyUnit 怎麼用。pyUnit 有含在預設的 modules 裡，抄幾段範例碼就能用了：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#------------------------------------------------- # Press F10 to execute the test case directly in VIM #-------------------------------------------------   import unittest   class MainTestCase(unittest.TestCase): def setUp(self): pass   def tearDown(self): pass   def testAMethod(self): self.assertTrue(True) self.assertEqual(2, 1 + 1)     if __name__ == "__main__": unittest.main()

結果沒找到 GUI 版的 pyUnit，少了精美的綠色進度表就不是 xUnit 了啊！

接下來演變為長期抗戰，裝好的 Python26 裡沒有 pyUnit 上提到的 unittestgui.py，而官網上的載點也失效了，好在可以從 code search site 找到： unittestgui.py。可是怎麼試都是載入失敗。最後在 pyUnit 官網找到另一個方案：GUI test runner using wxPython。

這份 unittestgui.py 用到 wxPython，所以得下載對應到 Win32 Python 2.6 的 wxPython，執行安裝檔後會自動找到 Python 2.6 的位置，而將預設路徑設為 Python26Libsite-packages，真是方便啊。原本還在擔心 Windows 下 Python module 要怎麼管理，結果很簡單。果然無知會造成恐懼。裝好 wxPython 後，再改一下 wxPython 版的 unittestgui.py (加上 import sys），就可以用漂亮的 GUI 版 Unit test 工具啦！而且是選檔案直接載入 test case，不用辛苦地填入 package/module path。

附帶一提，site-package 的設計簡單易懂，了解後以後要手動裝 module 也不成問題啦！

最後提一下 IPython 的相關訊息。IPython 比原本 python 內建的 interpreter 強太多了，是寫 python 的必備工具之一。IPython 首頁有列出下載的頁面，點 xxx.exe 下載執行，自然會裝到 site-packages 裡。官網首頁下方有指出 Windows 下要另外裝 PyReadline 才能正確執行 IPython，不然會沒顏色，且按 Tab 補字時會丟出 exception。IPython 的執行方式有幾種，這裡列出其中兩種：

• console mode：python Python26Scriptsipython
• GUI mode：python Python26Libsite-packagesIPythonfrontendwxipythonx.py

雖然是一樣的東西，總覺得 Unix 下用起來比較方便。

2009-02-23 更新

經 Scott Tsai 提醒，修正文中和 vim 相關的說明。沒想到才剛在 Plurk 提到「以後提到 Scott Tsai 可以加超連結了」，馬上就用到了。

2009-03-08 更新

修正 vim indent 的目錄路徑，並補上 IPython 的相關訊息。