Game of Life的「核心計算」部分寫好了，短短的沒幾行，畢竟也就那麼幾條判斷規則而已，沒什麼太複雜的東東要處理。說是寫好了，但到底能不能跑、跑出來的結果對不對，那可還是在未定之天哩。
測試程式寫得對不對，是件很讓人頭大的事。第一步，也是最簡單的一步，當然是檢查語法有沒有寫錯。語法的正確性，依照使用的程式語言，可以由compiler或interpreter來檢查，以Python來說，就是使用interpreter。通過了這一關也別高興得太早，真正麻煩的是後續的部分，因為機器可是沒辦法告訴你，因為手殘，你把a = b + c，寫成了a = b – c；或者是，沒注意到a是浮點數，結果寫出a == 0這樣的判斷式。還有啊，Python的變數是不用宣告的，所以萬一把變數名稱打錯了，例如把center_x = int(width/2)，打成centre_x = int(width/2)，那interpreter也不會認為那是個錯誤。這種不是語法錯誤的問題，就只能靠人來處理了。debug功力的重要性，可是不亞於程式寫作的功力的。那現在這個「核心計算」部分的程式要怎麼測試呢？先用個簡單的例子跑跑看結果正不正確好了。「柏拉圖的天空」這本書裡頭有個例子，剛好可以拿來用，跑出來的結果如果跟書上的結果一樣，就算初步過關。
測試用的例子有了，再來是，該怎麼呈現結果呢？畢竟只寫到「核心計算」部分，「視覺呈現」部分還沒動工。要看結果，最簡單的做法，就是把universe這個list給print出來，不過可得忍受畫面上一堆0、1和逗號。這倒無妨，先確定程式的正確性再說。
現在像Spyder這種IDE都有很好用的debug工具可以用，所以重點就在於，要怎麼找出有問題的地方然後修正。想找出有問題的地方，說難不難，可有時候又非常難。如果是像Game of Life這樣的程式，因為很單純，只要是相同的初始universe，就一定會有完全相同的執行過程和結果，所以錯誤的再現性很容易控制，找到問題點只是時間的問題。但如果是像牽涉到網路的程式，錯誤的再現性很難控制，那要找出問題點，可就沒那麼容易了。
修正幾個小問題後，總算，「核心計算」部分初步過關。唉！就只是初步過關而已啊，誰知道跑其他例子時，會不會又有問題。測試最困難的地方，就在於通常是沒有辦法把所有可能的狀況都試一遍。所以囉，也就只能盡量先把各種狀況考慮進去，保證至少在這些狀況下，程式是沒問題的。那以後又發現問題怎麼辦？就更新、修正咩！現在大家不是常常在那邊更新PC或手機的軟體嗎？就這麼回事。
說到測試，就不免想起微軟。以前微軟的Windows有新版要上市時，那可是轟動武林、驚動萬教的大事，就跟現在新iphone要問世一樣，很多人都引頸企盼。微軟很厲害，當Windows正式版本要出來之前，就會先出個「搶鮮版」，然後很多人就會搶著去買來嚐鮮。嚐鮮的結果就是一堆問題，然後微軟就趕快修正。等最後正式版本出來時，這些問題都處理掉了。多聰明的微軟啊！這些嚐鮮族不僅幫忙測試，還心甘情願付錢給微軟，這行銷手法實在是太高明了！
雖然微軟的行銷手法很厲害，不過再厲害、再高明的行銷手法，如果沒有相對應的產品品質，終究還是會被消費者給看破手腳的。現在的Windows，當有新版要推出，或者有新的更新時，雖然還是有許多人想要嚐鮮用看看，不過更多的人卻是避之唯恐不及，深怕更新之後不僅沒改善問題，反而帶來更多問題。有那麼好長一段時間，微軟強迫大家一定要馬上更新，沒得選擇，可是更新的結果，卻往往是哀鴻遍野、問題百出。搞到最後，各種躲避更新的手法紛紛出籠，Windows的更新，反倒成了令人聞之色變的災難了。
