其實TDD很簡單，只要你不把它當測試。沒錯，就這么簡單。把TDD當測試來寫，你想著的就是如何找出已有代碼的錯誤。想象著的是一副從迷宮中拯救出受困公主的圖景。這個時候你就會受困于該如何去測與測什么的問題。假若你不把TDD當測試來寫，頓時就會豁然開朗，撥云見日。
我認為TDD的本質在于，通過寫測試來寫代碼。也就是在每一行產品代碼落筆之前，先寫一個測試來給這行代碼找一個存在的理由。在參加TWU期間，一位名叫Garret Smith的培訓師（Coach）反復和我們強調任何一行代碼都要有測試。而且給我們舉了一個實際例子：公司的英國辦公室的一位同事編寫一個軟件專門用來對付無測試的代碼。方式就是一行行地刪除產品代碼，如果測試仍然能夠通過，這行代碼就被刪除了。這個例子給我的印象很深刻，因為我覺得它一語道破了天機。TDD其實就這么簡單，讓你的產品代碼不能隨便被別人“刪除”。
當用這個視角去實踐TDD的時候。測試的名字就會很細節化。具體到描述什么條件時以什么參數調用什么方法時會有什么返回值�；仡^一想，這些測試對應著是什么呢？其實就是javadoc文檔！那么TDD又是什么一個過程呢？就是先寫文檔再寫代碼的過程。這么一說來，TDD就很自然了。你先想到一個很簡單的功能要實現，有很多的代碼要寫。從一堆要寫的代碼中選擇出最簡單的部分（比如邊界的情況）來寫。把這部分代碼的外部行為想好，寫出對應的測試來，并給測試取一個能夠當文檔使的名字。
知道了TDD的本質與單元測試的本質之后，再來看一下我認為唯一關鍵的一個實踐，那就是Mock。沒有Mock的單元測試就很可能不是單元測試，也許是集成測試，也許是功能測試，總之不是TDD中所需要的那種能夠驅動你開發的測試。任何牽涉到兩個有行為的類之間交互的測試，都要Mock一個測另外一個，不然就會對象之間的互相影響就會使得測試測不準，無法確知問題所在，也無法讓你的測試能夠清晰地表達意圖。
也許以前有一些書籍或者人講過TDD只適合測算法，單元測試要做到黑盒，寫Mock要適度之類的話。我目前的認識是這些見解容易讓人把單元測試真當測試來看了。其實矯枉過正也無妨，就把TDD測試不當測試吧�？偨Y一下就是TDD是確保你的代碼不被別人意外“刪掉”的開發方式，單元測試是你產品代碼的文檔，Mock是編寫單元測試時最重要的技術，用于隔離測試對象行為。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/