你不會打無準備之仗，于是，你通讀了Kent Beck的那本薄冊子。通讀之下，你對TDD更是充滿了信心。因為“紅——綠——重構”的步驟實在是簡單得令人發指。好吧！總而言之，你已經信心十足的準備開始TDD，步入敏捷的康莊大道了。
理想很美好，現實很殘酷。
當你著手在實際項目中體驗TDD的時候，一切變得并不像最初看起來的那樣美好。雖然你努力的堅持著TDD的原則，但你經常就會發現某些東西不好測，比如你遇到了數據庫，比如你遇到了GUI，比如你遇到了計時器（Timer）。敏捷并非教條，當某些事不可為的時候，你完全可以不那么堅持。于是，你告訴自己，不好測的東西可以不測，這樣，至少從心理上來說，你覺得舒服多了。隨著工作的繼續，你發現，你不能測的東西越來越多，單元測試的覆蓋率隨著開發的進行正在逐漸降低，一絲恐懼涌上心頭�；剡^頭來，再去看Kent Beck的書，你突然覺得，你似乎被騙了，因為Kent Beck的例子貌似全都是邏輯，如果只是邏輯，當然好測了，但現實從來就不是這樣。
難道TDD只是看上去很美？
顯然，你不愿意就這樣放棄，放棄你苦心學來的軟件開發秘籍，那些傳說中的高手極力推崇的TDD必然有一定道理，TDD確實能夠讓你感覺很好：能測試的那部分代碼確實極大的增強了你對軟件質量的信心，而且出錯了也確實好找，每次修改代碼之后運行測試出現的綠條也確實讓你身心愉悅。
那問題到底出在哪呢？你陷入了沉思。
信馬由韁，你翻開了自己寫過的代碼�？粗约簩懙倪@些代碼，你忽然意識到一個問題，自己遇到的問題并不屬于TDD，而是屬于單元測試。正如你之前所想到的那樣，TDD做法本身的結果是讓你感到快樂的。對，一定是單元測試本身出了問題。那單元測試出了什么問題，很顯然，一大堆不能測試的部分讓單元測試變得很難寫，降低了單元測試的覆蓋度。那是不是這會是一個無解的問題呢？你顯然不愿意就此放棄，所以，順著這個思路繼續向前。
文章來源于領測軟件測試網 http://www.kjueaiud.com/