訂閱本網誌: Facebook, Google+, 電子報, RSS

Coding: 寫 Test 還是不寫 Test?

September 1st, 2011 by Jamie

appWorks 有一些問題我們常常討論,例如:用什麼工具、做什麼產品、該怎麼行銷、該跟誰合作、怎麼合作、什麼時候增資、該拿多少錢… 等等,這些問題往往沒有一定的答案,也必須要視情況而定。但越是沒有標準答案的,我認為越是應該多討論,這樣才能幫助創業者們根據自己的情況,定義出最適合自己的處理方式。

而關於 coding,「要不要寫 test」就是其中有一個這樣的問題。我個人的意見是當你要做一個非常簡單、用完即丟的 MVP,那不必寫 test。如果邏輯比較複雜、日後有維護的必要或是有和人家協同工作,那你一定要逼迫自己寫 test。

這絕對不只是完整性、邏輯性或是身為一個工程師的職責問題,而是你如果不寫 test,就是跟自己過不去 — 跟好的 comment/documentation 一樣,不做的話,日後要維護時,你將會花更多時間在弄懂自己當初寫的 code,當別人要用你的東西,你也必須花更多時間跟他解釋,這不就是跟自己過不去嗎?

我得承認關於更深入的判斷什麼時候要寫 test、該怎麼寫,我不是專家。但是今天讀到一篇文章寫得很好,在這裡跟大家分享。

  1. Test 讓你用程式功力去挑戰你的程式功力 — 身為工程師,大家最討厭的就是不斷的手動測試了,那何不把這些寫成程式?況且最好的進步方法就是以己之矛,攻己之盾,這樣不斷的循環下去,你的程式功力一定突飛猛進。
  2. Test 讓你跟你寫的程式還有你自己對話 — 當你若干時間之後回來看自己寫的 test,你將會重新檢視自己當初的邏輯 — 這樣複雜的錯誤處理真的有必要嗎?這個物件夠獨立嗎… 等等,並且想清楚你寫的程式跟整個系統的架構是否吻合。
  3. Test 提醒你程式是用「用了」多少行衡量,而不是「寫了」多少行 — 記住,最棒的程式碼,不是程式碼
  4. 好的 Test 設計還包含好的 Test 註解 — 如果你寫好的測試,別人更容易了解你的程式,和如何跟你介接。
  5. Test 讓你可以看穿別人寫的 code — 同樣的道理,如果大家都寫好的測試,那你可以更容易了解別人寫的 code,大家都會進步的更快。

以上,就是一些關於寫 test 這件事情的觀念,希望能夠讓你更認同 test code 的價值。或許你有更有趣的經驗?歡迎留言跟大家分享。

想要在臥虎藏龍的 appWorks 跟高手們一起創業?第四屆 appWorks 育成計畫歡迎你的加入。

(image via richardmoross, cc license)

歡迎訂閱 MR JAMIE 電子報
讓新文章自動寄到你的信箱

©2024 MR JAMIE.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成