想了半天，確實是記不得什麼時候第一次聽說tdd了，我這裡是要拍(拍板磚的拍)這個所謂的tdd，所以也就懶得去找tdd到底是什麼時候提出來的，雖然google一下可能在第一頁就能有正確的命中(比如wiki百科，哦可惜不能訪問了)。對tdd我還是了解一點點的，至少知道它被大家叫做test drive development，不過我覺得過分強調這個東西真的有些無聊，甚至是相當的無聊。
高質量的程式是程式設計師編寫出來的，而不是測試出來的。所以對於程式編寫，測試如果是錦上添花，那麼最終結果是非常棒的。而如果測試成為了雪中送炭，那麼這個產品或專案注定了就是一坨屎。程式的質量和tdd有什麼關係呢？
tdd是束縛程式設計師生產力的桎梏，同時tdd也是程式設計師推卸和逃避責任的法寶。程式設計師是思考型的工作者，而不是流水線上的裝配工人。雖然今天在一些特定的場景裡，程式設計師可以像標準件一樣被任意的替換，但不得不說這樣的程式設計師其實就是編碼工人而已，就像拿到圖紙後就知道該怎麼砌磚的建築工人一樣。為什麼說tdd阻礙生產力？這很明顯，編寫測試用例需要時間和精力呀。當然很多人會說自測試是程式設計師的責任，如果不編寫測試用例，不做unit test，怎麼來保證程式設計師的**質量？程式設計是一種還算有些創造性的工作，而不是挖乙個坑種乙個蘿蔔的機械勞動。測試用例只是對矛盾的一種轉換，比如我應該讓我的程式處理3種輸入，結果我把這個任務轉換成了：我有3個測試用例，我的程式需要通過這3個測試用例。到底程式設計師是在幹嘛？為了測試用例而程式設計嗎？由於測試用例也是程式設計師自己寫的，所以測試用例的錯誤和失誤風險和程式的風險等效。實際上程式設計師還是在為自己程式設計，為自己的思考程式設計。這樣一來到底是自己的思考犀利敏銳，還是把思考變成了測試用例更加有效？我覺得自然的思考最有效率，而用心的思考最有效果。而隔了一層測試用例的思考，使人更加容易出錯和生長惰性，因為增加了步驟和莫名的依賴，覺得通過測試用例就萬事大吉。殊不知自己編寫的測試用例只是思考的一種轉換，一種更加難以把握重點和實質的轉換，因為程式設計的動力已經變成test的結果了。
關於使用tdd來重構更是騙小孩的把戲。tdd強調的就是要通過測試，別的都不再重要。任何"多餘"的功能，就是unit test case沒有覆蓋的功能，就沒有了任何實現和處理的價值，編寫這樣的處理**被認為莫名其妙，因為它們不會被測試，也沒有這樣的unit test case。作為乙個真正的程式設計師，是不會容忍初始的**實現是一坨屎，然後再來根據什麼test case重構成perfect的**的。因為第一次的思考一般是嚴肅的，第一次編寫的**是最有靈犀的，它不是在後來懶心無腸就能修改出來的。反而後來的**更多的就是為了亮綠燈而已，效率和美感蕩然無存。這有點像是在汙衊真正認真重構**的人吧？其實不是，如果你真是認真地人，為什麼在開始不仔細思考，把那些編寫所謂test case的時間用來編寫好你的第一版**，然後認真地用"心"執行幾次呢？因為這樣的代價其實是在debug時不可避免的，如果真要完全(注意是完全)依賴綠燈，這也就是嚴重的開發效率問題了。
版本公升級和延續又真的能依靠tdd嗎？首先我們假設公升級和延續的改動是有限的，否則成了重寫就不在這個討論之列了。測試依靠測試用例，測試用例如同**注釋、開發文件，它們同樣存在著過時和與實現不同步的問題，這都需要維護。而且寫得ugly的unit test case和濫注釋濫文件是一樣的，到後來根本沒有用也沒有任何人願意再去維護修改趟這個渾水。真正的版本公升級和延續的保障是product team人員的穩定。如果從設計到實現甚至測試，主要人員都很穩定地一直做下來，那麼新的設計和改動實現後要不穩定都難。這是tdd能drive的嗎？一些惜墨如金的注釋，一堆莫明其妙的開發文件、囉裡囉唆的n多unit test case，不知道新來的人面對後怎麼開始他的延續工作？
所以到底什麼是tdd？什麼才是有效的tdd？真正的tdd應該是：thinking drive development。真是鬱悶，縮寫還居然一樣，算了，就沾點惡名吧。程式設計師進行直接的縝密思考，他提交的**才會是***y的，他的開發效率也才會是最高的，所謂磨刀不誤砍柴功正是如此。而unit test case、unit test只是開發方法有益的補充，不是主要矛盾所在。
都在說TDD開發,那到底TDD是什麼
想了半天，確實是記不得什麼時候第一次聽說tdd了，我這裡是要拍 拍板磚的拍 這個所謂的tdd，所以也就懶得去找tdd到底是什麼時候提出來的，雖然google一下可能在第一頁就能有正確的命中 比如wiki百科，哦可惜不能訪問了 對tdd我還是了解一點點的，至少知道它被大家叫做test drive de...
TDD 測試驅動開發
test driven development 測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種設計方 tdd的原理是在開發功能 之前，先編寫單元測試用例 測試 確定需要編 寫什麼產品 tdd雖是敏捷方法的核心實踐，但不只適用於xp extreme programming 同樣可以適用於其他開...
TDD 開發理論 原創
通過測試來推動整個開發的進行，但測試驅動開發並不只是單純的測試工作，而是把需求分析，設計，質量控制量化的過程。l 分析並確定乙個目標測試場景 l 新增乙個單元測試來驗證該測試場景的輸入輸出 l 執行該測試，得到失敗的測試結果 l 寫最簡單的功能 來通過該測試 l 再次執行該測試，看到測試通過 l 進...