隨手google到gigix的blog，看了一些他的觀點和若干人等的相關評論，有些覺得頗有道理，摘錄如下。
看“測試驅動開發”這個名字，首先應該明確：與它對應的是“文檔驅動開發”。它是一種開發過程，這裏的測試是一個設計問題，而不是QA問題。在沒有 TDD之前，“正統的”開發過程要求有設計文檔：高層設計描述一個模塊“做什麼事”，詳細設計描述一個模塊“如何做這些事”。軟件工程課講得清楚，只有源代碼的軟件不能算軟件，因爲它不可理解、不可維護；源代碼加上文檔，纔算是程序員完整地交付了自己的工作。要做任何一件事之前，你必須首先清楚地知道自己要做什麼（以及不要做什麼），否則那就是crack，不是在從事職業的軟件開發。
但這種文檔有幾個致命的缺陷。第一，自然語言的描述容易產生歧義；第二，不能自動化地驗證；第三，不能保證文檔與程序同步。測試驅動開發正是爲了解決這些問題而產生的。在編寫一段代碼之前你所寫的測試，不是爲了確保這段代碼不出錯，而是爲了描述你想要做的事情。當你擁有這個測試之後，持續集成會始終確保你的代碼恰好是做了你想要做的事情。測試驅動開發是一種設計方法，它清晰無二義地描述你的設計，並保證設計與實現一致。
所以幾個典型的問題就可以很清楚地找到答案。單元測試要不要是白盒的？要。因爲你是在描述如何實現這個模塊，而不是驗證它的輸入輸出正確性。單元測試要不要把每個模塊放到真實的事務或者併發環境下測試？不要。因爲你只是描述當前模塊的實現，真實環境下的正確性由集成測試和QA來保證。爲什麼模塊內部實現的變化要同時導致測試變化？因爲你的思路、你的設計變化了，你應該有一個文檔描述這件事情。
（如何用unit test測試私有方法）...重點在於，你不應該有任何方法是從一開始設計出來就是private的，因爲你的每段程序都應該在單元測試的驅動之下產生，而測試是不可能驅動出來一個private方法的。那麼private方法從哪裏來？只能從重構而來。所以答案是：private方法是不需要測試的，因爲它是重構的產物，而重構是不改變程序可觀察之行爲的。既然行爲不改變，測試自然也不需要有任何改變，所以不需要針對private方法建立任何新的測試。
但是，如果private方法確實出現問題了怎麼辦？如果你確實希望用測試來弄清一個private方法裏面到底發生了什麼，該怎麼辦？
答案是：如果一個private方法複雜到你不能一眼看清它，那它就太複雜了，你應該把它重構成爲一個獨立的class，然後針對這個class來建立單元測試
關於這個對private方法的單元測試，記得兩年前我在bbs上跟別人有過討論，當時對單元測試的理解太粗淺了。現在我的理解跟gigix基本上是一致的。嗯，雖然這一年多基本上沒寫過unit test-_- 但有些東西還是在不知不覺中進步的啊。就好像下棋一樣，對棋的理解確實會隨着時間的增加而逐漸提高，當然這種提高是很有限的，並且距離實戰還有很大的距離，必須多進行一些實際的對局才能把這種提高轉化成真正對自己下的棋所有幫助的東西，或者說必須和實戰所結合起來。不然的話，所謂的提高就只會讓你的棋漏洞百出，被對手打得落花流水。
遇到什麼東西不由你選。要是程序員可以決定自己將要遇到什麼東西，用匯編寫寫就可以了，還搞什麼這個P那個P，結構化都用不着。
另外說句廢話——o6z也許又要罵我，不過這話我覺得不能算和職業無關——我最討厭程序員自以爲是的批評什麼“鬼東西”、“垃圾設計”。就是這些“垃圾設計”的“遺留系統”，運轉着銀行的絕大多數業務邏輯，創造着證券業信息化系統的絕大部分價值。沒錯，用2004年的眼光（甚至是1998年的眼光）來看，它們是腐爛代碼，它們是垃圾設計。但我們自以爲是的那些優秀設計，它們做了什麼？它們不過是在運轉一些邊沿業務，提供幾個漂亮的網站展示而已。說白了，這些東西纔是可有可無的垃圾。可以運轉的程序就是好的程序，正常運轉了超過十年的程序是精彩絕倫的程序，不懂得敬畏這些程序的人，做不好企業級應用。
這段牢騷說的也有點道理。但我覺得，這並不是歷史發展的趨勢。將來恐怕還是那些“我們自以爲是的那些優秀設計”的天下，即使它們現在看上去是“可有可無的垃圾”。那些“正常運轉了超過十年”的“精彩絕倫的程序”，也許還將繼續運轉下去，但是這些程序所佔的比重只會越來越少。就如同資本主義的工業化戰勝了封建行會的手工作坊，就算有些天才的技術工人能夠製造出高超的產品，質量比機器生產出來的東西要高得多，但這阻擋不了機器的社會化大生產成爲潮流，而那些有着頂尖技法的天才，終究不會成爲主流。軟件的發展也會使進入的門檻越來越低，這時那些集中着天才智慧的程序的用武之地會越來越小，能夠推動每個熟練工人生產力的提高才是更重要的東西。畢竟不可能每個人都是天才。
