學習tdd(1)tdd的步驟和好處：加入乙個新的測試 執行下新加的測試，看到它失敗(因為你還沒寫功能**) 對開發**做很小的修改，目的就是讓新加的測試通過 (注意這裡的目的) 執行所有的測試(test case)。
然後看到所有測試都通過了 (看到測試都變成綠色，一般都會小開心一下) 移掉重複的**，對**進行重構 (既包括功能**，也包括測試**。特別注意紅色的字串 一般會有重複，還有一些**可以抽出來變成公用方法，測試**中同樣的初始化和還原測試環境的**，可以放到intilize和cleanup中去)
而外還有一些步驟也是可以加入的，比方
在寫測試**前，先從需求出發，準備乙個test list (需要測到的功能的列表)。忘掉你該怎麼實現，那是後面的事情 每測完乙個就用橫線劃掉 如果發現有漏掉的test 就加到這個列表中(列表測完你的功能也就完成了)
tdd能帶來的好處
你會更加站在使用者的角度去看你將要完成的產品，你要盡可能想到使用者所有進行的操作。而不是從程式設計師的角度想使用者應該會如何去使用我們的產品。
測試用例是在對功能進行測試。在寫**之前先寫測試用例，可以對我們編寫**提供指導性的參考。防止我們漏掉一些功能。
它使我們對自己**有了信心，因為我們事先設計好的所有測試用例都pass了。
如果在更改**後測試用例不能通過，我們可以根據不能通過的測試用例精確的定位問題，並輕而易舉的解決的這個bug。
哈!我們的一整套完備的測試用例在這裡替我們把關(把的什麼關?)，我們就可以十分安全的使用極限程式設計的另乙個最重要的工具——重構。重構改變的是**的內部結構，而不會改變外部介面功能。知道在做重構時測試用例是把的什麼關了吧!很明顯，測試用例是保證我們在進行重構時，不會影響到**的外部介面功能。所以我剛剛說，我們進行的重構是十分安全的。
基於第5點，我們找到了重構的信心，必要時候你還可以痛痛快快的並且滿懷信心的對**做一場大的變革。這樣我們的**變得乾淨了，擴充套件性、可以維護性以及易理解性紛至沓來。
首先站在客戶方**的立場，可以獲得更好的api。
其次可以改善軟體質量，支援重構。
其三，大幅減少debug時間。
前期投入大，後期能大幅縮短開銷，將問題發現在最源頭
提供明確的目標:
你很清楚, 一旦結束(測試通過), 你的工作就完成了(假設你的測試寫的很好). 測試**會為**建立乙個自然的邊界, 使你把重點集中在當前任務上. 一旦測試通過, 就有確切的證據證明你的**能工作. 相對於人工的測試使用者介面或者比較日誌檔案中的結果, 在乙個xunit框架中執行自動化測試, 速度要快幾個數量級. 大多數xunit測試的執行只需幾微秒, 而且大多數採用tdd的人都會一天執行數次測試. 在許多開發小組中, 將**上傳配置庫前, 必須成功地通過測試.
提供文件
你是不是經常遇到看不懂的**? 這些**可能沒有任何文件說明, 而且開發**的人可能早就走了(或者去度假了). 當然看到這種**的時間往往也很不合時宜, 可能是凌晨3點, 也可能有位副總在你旁邊大聲催促著趕快解決問題, 這樣要想花些時間來願作者的意圖就更困難了. 我們見過一些好的單元測試文件, 它們會指出系統要做什麼. 測試就像原開發人員留下的記號, 可以展示他們的類具體是怎麼工作的.
改善設計
編寫測試能改善設計. 測試有助於你從介面的角度思考, 測試框架也是**的客戶. 測試能讓你考慮得更簡單. 如果你確實遵循了」盡量簡單而且行之有效」的原則, 就不會寫出篇幅達幾頁的複雜演算法. 要測試的**通常依賴性更低, 而且相互之間沒有緊密的聯絡, 因為這樣測試起來更容易. 當然, 還有乙個額外的作用, 修改起來也會更容易!
鼓勵重構
利用一套健壯的測試集, 你能根據需要進行重構. 你是不是經常遇到一些不知是否該修改的**? 種種的顧慮讓你行動遲緩, 過於保守, 因為你不能保證所做的修改會不會破壞系統. 如果有一套好的單元測試集, 就能放心的進行重構, 同時能保證你的**依然簡潔.
提高速度
編寫這麼多測試會不會使開發速度減慢呢? 人們經常會以速度(或開發開銷)作為反對進行tdd和使用xunit框架的理由. 所有的新的工具都會有學習曲線, 但是一旦開發人員適應了他們選擇的框架(通常只需要很短的時間), 開發速度實際上會加快. 乙個完備的單元測試集提供了一種方法對系統完成回歸測試, 這說明, 增加乙個新特性之後, 你不必因為懷疑它會不會破壞原系統而寢食難安.
提供反饋
單元測試還有乙個經常被忽略的優點, 即開發的節奏. 儘管看上去好像無關緊要, 但通過測試之後你會有一種完成任務的成就感! 你不會成天地修改**而沒有任何反饋, 這種測試-**-測試的方法會鼓勵你動作幅度小一些 通常修改一次**的時間僅僅幾分鐘而已. 這樣你不會一下子看到冒出一大堆新的特性, 而只是讓**每次前進一小步.
tdd的缺點
tdd有這麼多好處，但它也不是免費的午餐，它需要我們有設計完備的測試用例的能力(這項能力是長期理論與實踐的結合體)，否則你將會吃了虧編寫了一大堆測試用例，卻沒測到點子上。可怕的是，你還對你「測試通過」的糟糕的**滿懷信心。
質量是反覆思考的結果，僅靠解決bug無法獲得。
學習TDD 1 TDD的步驟和好處
早就聽說tdd的大名，一直沒有機會使用。這次mrpc框架開發的時候正好用用看。在此之前，先學習一下tdd。本篇大部分結論來自 加入乙個新的測試 執行下新加的測試，看到它失敗 因為你還沒寫功能 對開發 做很小的修改，目的就是讓新加的測試通過 注意這裡的目的 執行所有的測試 test case 然後看到...
敏捷測試（1） TDD概念
本系列筆記將從測試兩年來的測試經驗，記錄乙個完整的基於敏捷流程的驗收測試全過程，分享在測試過程中的一些知識和經驗，以及自己的一些理念。總結自己，也希望對大家有益。驗收測試驅動開發 atdd 和測試驅動開發 tdd 是完全不同的兩個概念。tdd更偏重自動化case先行，而atdd更偏重於驗收細節 質量...
我的TDD實踐
我的tdd實踐 系列之unittest單元測試寫在前面 tdd實踐系列文章 1.tdd概念篇 2.ci持續整合 3.svn架設篇 4.unittest單元測試 1.2 特徵 與其他 相隔離 單元測試只測試一件事，否則應該懷疑是否是測試內容有誤。與其他開發人員隔離 保證最小化的變數影響單元測試，也就是...