作為軟件開發工程師,做測試還是不做測試？

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

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

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

　　我得承認關于更深入的判斷什么時候要寫測試、該怎么寫，我不是專家。但是今天讀到一篇文章寫得很好，在這里跟大家分享。

　　1.測試讓你用程序功力去挑戰你的程序功力—身為工程師，大家最討厭的就是不斷的手動測試了，那何不把這些寫成程序?況且最好的進步方法就是以己之矛，攻己之盾，這樣不斷的循環下去，你的程序功力一定突飛猛進。

　　2.測試讓你跟你寫的程序還有你自己對話—當你若干時間之后回來看自己寫的測試，你將會重新檢視自己當初的邏輯—這樣復雜的錯誤處理真的有必要嗎?這個對象夠獨立嗎…等等，并且想清楚你寫的程序跟整個系統的架構是否吻合。

　　3.測試提醒你程序是用「用了」多少行衡量，而不是「寫了」多少行–記住，最棒的程序代碼，不是程序代碼!

　　4.好的測試設計還包含好的測試批注—如果你寫好的測試，別人更容易了解你的程序，和如何跟你介接。

　　5.測試讓你可以看穿別人寫的編碼—同樣的道理，如果大家都寫好的測試，那你可以更容易了解別人寫的編碼，大家都會進步的更快。

原文轉自：http://www.kjueaiud.com