在項目實踐中使用TDD，我經常會被問到以下問題，這讓我很無助：
- TDD可以幫助你設計嗎？
- TDD可以幫助你明確需求嗎？
- TDD可以幫助提高質量嗎？
- TDD是正確的嗎?
- TDD有經過科學的收集數據，通過數據對比來驗證嗎？
這些問題都很常見，讓我無助的不是這些問題答不上來 - 其實都有很明確的答案，讓我無助的是也許大家在項目實踐中遭受太多苦難，當大家發現一個有用的工具或者方法論時，無不寄希望于她能幫助我們解決所有的問題。其實人家Fred Brooks早在1987年就看穿了這一點，并發表了一篇關于咱們這個行業-軟件工程的經典論文《沒有銀彈》。核心思想就是 - 沒有任何一項技術或方法可以讓軟件工程的生產力在十年內提高十倍。Fred Brooks已經把這個期限放的很寬了，十年。我認為這個“十年”絕對是打破幻想的精準一擊，話外語就是，不管我給你多少年，你也還是一樣找不到這樣一枚銀彈，是不是有點絕望。再看看以上問題的“正確”答案，你因該會更絕望：
- TDD可以幫助你設計嗎？
不能，如果你本身就不會好的設計，那也沒有一種方法能讓你一下就會。
- TDD可以幫助你明確需求嗎？
不能，需求如果本身就不明確，也沒辦法通過TDD讓她明確。
- TDD可以幫助提高質量嗎？
不能，如果你寫的代碼質量就是不行，不管用什么辦法，你寫出來的肯定還是自己的代碼。
- TDD是正確的嗎?
不知道，還沒有誰通過科學的辦法驗證這個是否正確。
- TDD有經過科學的收集數據，通過數據對比來驗證嗎？
沒有，因為這個過程中的變量因子太多太多，自身能力的成長就是不可衡量因子其中之一。
什么？看起來TDD一無是處？從上面的答案來看，我還真沒法反駁你，但我仍然選擇堅持TDD。
我現在的一項主要工作就是培訓新入職的畢業生，希望公司的敏捷文化在最開始的時候就可以盡可能全面的呈現在大家面前，讓大家知道什么是我們鼓勵的，什么是我們向往的。
在我們的培訓中，TDD被我們設計成OOBootCamp中第一個重要的環節，在這之前會有敏捷簡史的介紹，用來幫助大家理解大的背景。也有關于單元測試的介紹，幫助大家了解單元測試，從而能夠區分哪些是測試帶來的好處，哪些是TDD帶來的。
之所以堅持，當然不是因為需要堅持而去堅持，而是如何真正的去了解她，知道如何跟她Pair(結對兒)。
TDD是一個方法論，和GTD - 時間管理、 PKM - 個人知識管理一樣，只是一個方法論。
TDD能夠提高編碼的效率，能夠盡量避免糾結，節約你的時間。當你一個人不知道先做什么后做什么的時候是，當兩個人結對兒的時候尤是。
通常與TDD同時出現的詞還有 Unit Test(單元測試，我們這里的TDD指的是uTDD)， Pair(結對兒編程)。
TDD可以保證Pair質量，保證雙方都能動手實踐，思路統一，增強參與感。
設定了以上期望，我相信TDD能更好的為你所用。畢竟能夠幫助我們解決實際問題，才是王道。
