對於測試驅動開發，老外衆口一詞十分推崇，國內有人贊成 有人反對。雖然暫時還沒有開始這方面的嘗試，在這裏只是羅列一些雙方的觀點，做一些思想上的準備。
關於更深入的判斷什麼時候要寫測試、該怎麼寫
1.測試讓你用程序功力去挑戰你的程序功力—身爲工程師，大家最討厭的就是不斷的手動測試了，那何不把這些寫成程序？況且最好的進步方法就是以己之矛，攻己之盾，這樣不斷的循環下去，你的程序功力一定突飛猛進。
2.測試讓你跟你寫的程序還有你自己對話—當你若干時間之後回來看自己寫的測試，你將會重新檢視自己當初的邏輯—這樣複雜的錯誤處理真的有必要嗎？這個對象夠獨立嗎…等等，並且想清楚你寫的程序跟整個系統的架構是否吻合。
3.測試提醒你程序是用「用了」多少行衡量，而不是「寫了」多少行–記住，最棒的程序代碼，不是程序代碼！
4.好的測試設計還包含好的測試批註—如果你寫好的測試，別人更容易瞭解你的程序，和如何跟你介接。
5.測試讓你可以看穿別人寫的編碼—同樣的道理，如果大家都寫好的測試，那你可以更容易瞭解別人寫的編碼，大家都會進步的更快。
要不要寫測試?看情況而定
我個人的意見是當你要做一個非常簡單、用完即丟的MVP，那不必寫測試。如果邏輯比較複雜、日後有維護的必要或是有和人家協同工作，那你一定要逼迫自己寫測試。
所有的測試必須在幾秒鐘內能跑完，否則的話，程序員不得不頻繁的停下來等待測試
“可是怎樣才能讓它們快起來？”他問，“光連接數據庫就需要30秒”。於是，我想他展示了一種叫做依賴注入的技術，它能讓你使用一個僞造對象來模擬數據庫。“你並不需要測試你數據庫，”我說。“記住，測試應該是測試那些不受控制的東西，對於測試所依賴的東西，你應該使用模擬工具使它們處於控制之中。”這絕對不只是完整性、邏輯性或是身爲一個工程師的職責問題，而是你如果不寫測試，就是跟自己過不去—跟好的comment/documentation一樣，不做的話，日後要維護時，你將會花更多時間在弄懂自己當初寫的編碼，當別人要用你的東西，你也必須花更多時間跟他解釋，這不就是跟自己過不去嗎？
測試程序不但沒起到好的作用，反而成了一個負擔。“我們三天兩頭的要重構程序，關聯的就需要重構測試程序”
這種問題是他們把TDD想成了QA。TDD不是QA。QA是來保證程序能正確的運行的。TDD是使用斷言(assertion)來表現系統的關鍵特徵。在QA裏，我們用儘可能多的方法來測試系統中可能會出錯的地方。在TDD裏，我們用應儘可能少的測試來表現系統的關鍵特徵。
重視代碼質量，而不重視測試程序
當系統出問題時，測試程序就體現出來了它最大的價值，至少對我來說是最欣慰的時候。然而，對於系統，任何一個改動只應會讓一個測試失敗。換句話說，沒有任何兩個測試的失敗原因是相同的。這說起來容易做起來難，但如果你尊重這個原則，你將會發現，當你重構代碼時，重構測試程序是會容易多了。總之，測試也是程序，它們也要保持高質量。系統中的每個關鍵特徵都用一個測試來表現，沒有第二個測試會因爲這同一個問題而失敗。
（持續更新）