作為乙個有理想、有追求的程式設計師，你成天被各種名詞包圍著，你對其中乙個叫做敏捷的東西特別感興趣，因為它特別強調人的作用，這聽著都讓做程式設計師的你感到舒服。為了讓自己早日敏捷起來，你從眾多的敏捷實踐中選擇了乙個叫做測試驅動開發（test driven development，tdd）的作為你的起始點。因為它對你周遭的環境要求是最低的：它不像結對那樣，要求其他人和你一起合作；也不像採用story那樣改變你所在團隊的做事方式……你所需要做的，只是在你編寫業務**之前，把測試先寫好。這完全是一種潤物細無聲的做法，根本無需告訴你之外的任何人。就在別人忙碌的找bug時，你便開始享受敏捷帶給你的快樂了。順便帶來的好處是，下次在那裡和別人爭論敏捷的時候，你可以以乙個實踐者的姿態出現，而不是在那裡信口開河。
你不會打無準備之仗，於是，你通讀了kent beck的那本薄冊子。通讀之下，你對tdd更是充滿了信心。因為「紅——綠——重構」的步驟實在是簡單得令人髮指。好吧！總而言之，你已經信心十足的準備開始tdd，步入敏捷的康莊大道了。
理想很美好，現實很殘酷。
當你著手在實際專案中體驗tdd的時候，一切變得並不像最初看起來的那樣美好。雖然你努力的堅持著tdd的原則，但你經常就會發現某些東西不好測，比如你遇到了資料庫，比如你遇到了gui，比如你遇到了計時器（timer）。敏捷並非教條，當某些事不可為的時候，你完全可以不那麼堅持。於是，你告訴自己，不好測的東西可以不測，這樣，至少從心理上來說，你覺得舒服多了。隨著工作的繼續，你發現，你不能測的東西越來越多，單元測試的覆蓋率隨著開發的進行正在逐漸降低，一絲恐懼湧上心頭。回過頭來，再去看kent beck的書，你突然覺得，你似乎被騙了，因為kent beck的例子貌似全都是邏輯，如果只是邏輯，當然好測了，但現實從來就不是這樣。
難道tdd只是看上去很美？
顯然，你不願意就這樣放棄，放棄你苦心學來的軟體開發秘籍，那些傳說中的高手極力推崇的tdd必然有一定道理，tdd確實能夠讓你感覺很好：能測試的那部分**確實極大的增強了你對軟體質量的信心，而且出錯了也確實好找，每次修改**之後執行測試出現的綠條也確實讓你身心愉悅。
那問題到底出在哪呢？你陷入了沉思。
信馬由韁，你翻開了自己寫過的**。看著自己寫的這些**，你忽然意識到乙個問題，自己遇到的問題並不屬於tdd，而是屬於單元測試。正如你之前所想到的那樣，tdd做法本身的結果是讓你感到快樂的。對，一定是單元測試本身出了問題。那單元測試出了什麼問題，很顯然，一大堆不能測試的部分讓單元測試變得很難寫，降低了單元測試的覆蓋度。那是不是這會是乙個無解的問題呢？你顯然不願意就此放棄，所以，順著這個思路繼續向前。
tdd之所以讓你安心，主要是每次編寫**之後，執行測試會出現乙個綠條，告訴你測試通過。這樣，你可以放心大膽的向前繼續，因為你的**並沒有破壞任何東西。究竟是什麼讓你感到不安，顯然是那些測試沒有覆蓋到的**。你又仔細翻看了一下那些沒有測試覆蓋的**，你的思路一下子清晰起來。之所以這部分讓你不安，因為裡面除了那些確實不好測試的部分之外，裡面還有一些邏輯。如果只是那些真正不好測試的部分沒有被測試覆蓋到，你會覺得心裡還有一些安慰。你確定了，真正使你不安的就是與不好測試的**共存亡的這些邏輯部分。
如果測試可以覆蓋到這些邏輯的部分，至少從感情上來說，就可以接受了。那怎麼才能讓這些部分被測試覆蓋到呢？你仔細觀察著那些沒有測試的**，如果這樣做，這個部分就可以測試了，如果那樣做，那個部分也可以測試了，一來二去，這些貌似不可測試的**可以分解出許多可以測試的部分。
你的心情一下子好了許多，因為這麼做終於可以讓測試的覆蓋度達到讓你心理上可以接受的範圍。不過，新的問題也隨之而來。我在做什麼？拆來分去，這不就是設計嗎？怎麼走到這裡來了。我不是在分析單元測試的問題嗎？對了，我最初的問題是tdd，怎麼一路跑到設計上來了？
tdd？設計？
你突然發覺自己對tdd的理解有一些偏差。tdd，並不代表不需要設計。讀過很多書的你突然想起了robert martin那本著名的《敏捷軟體開發》，上面有乙個關於資料庫訪問的例子。那個例子裡面，前後兩個版本的差異正好就是考慮設計的結果。通常，在設計中考慮測試，會很容易找到設計中僵硬的部分，讓程式更加靈活。再進一步，如果在開始動手之前，稍微進行一些設計，這些問題還是可能注意得到的。你突然覺得，正是因為tdd本身過於強調測試的價值所在，讓你忽略軟體開發中很重要的部分：設計。
思路一下子清楚起來，tdd其實不只是「紅——綠——重構」，它還是與設計相關的：在動手之前，還是要有一定的設計，而且，在設計中要考慮測試的問題。終於解開了心中的困惑，現在的你，對於tdd有了乙個新的認識，雖然這個認識不見得是什麼終極真理，但至少是通過自己的思考得來的，這讓你更加相信實踐出真知的道理。
理清思路後，你更加堅信tdd本身的價值所在，也堅定了在日後開發中繼續使用tdd的念頭，當然，目光遠大的你已經盯上了其它的敏捷實踐。
Android測試驅動開發實踐
在android應用開發中，相信很少有人在堅持先由設計人員做完整的概要設計 詳細設計，然後交給程式設計師進行編碼實現了。通常是在有乙個大體框架的情況下，就開始進行具體編碼開發了。在這種情形下，開發速度可以有很大的提高，但是最終 質量卻不可避免的降低了。如何能既保持開發速度，同時又能保證開發質量呢？相...
測試開發驅動實踐
最近，測試驅動的概念慢慢被大家接受，kent back的書 測試驅動開發 中文版，也有中國電力出版社出版了。從2002年就開始，我使用測試驅動的方式開發，這兩年多裡，幾乎我所有的 都是基於測試驅動的方式進行開發。使用這種方式進行開發兩年，自然也有一些經驗。我這兩天看了kent back的 測試驅動開...
測試驅動實踐
wms3.0 的後台業務部分採用了測試驅動的開發方式。在開發過程中，對 pbunit 做了一次比較大的公升級，讓測試變得更容易和穩固。在我們的 tdd中，與標準的 tdd還是有一些不同的，在此列出我們的 tdd過程 1 設計，定義介面 2 測試概要設計 在 excel 中定義測試的場景 輸入 輸出 ...