是的，現在肯定有讀者會這樣說了：「我只在產品髮品之前寫測試。」有些人可能會竊笑，對質量保證部門說三道四。還有一些人作為專案經理可能會添油加醋地說：「我們可不會浪費時間寫測試**；我們還得寫真正的**呢。」那麼，採用tdd到底是什麼意思呢？
tdd產生於敏捷開發運動，特別是極限程式設計（extreme programming，xp），而且tdd正是xp的乙個核心原則。推崇tdd的人認為，不應該完成開發之後再寫測試，這通常只是「馬後炮」，而應當在寫**之前先寫測試。測試本質上相當於設計文件，而不是花大量時間去擺弄乙個複雜的圖形化工具，你要直接在**中「擬畫」乙個類。開始時先為一些小功能塊編寫測試。在有些語言下，你寫的測試甚至不能編譯，因為所引用的類尚不存在。一旦建立了測試，就可以執行這個測試（當然，此時執行測試會失敗）。然後再編寫最少量的**，以便測試通過。接下來再重構**，並增加更多的測試。
通常可以使用測試框架來幫助編寫自動化測試。最著名的框架是junit，不過現在已經有很多xunit專案，可以簡化在各種語言下測試的建立。一般地，這些框架都建立在斷言（assert）基礎上。開發人員編寫測試方法，將呼叫方法的實際結果與期望結果進行比較。當然，可以人工地檢查乙個日誌檔案或使用者介面來完成這些比較，但是，用計算機完成資料比較不僅速度快，也更準確。另外，就算是讓計算機把同樣的測試執行上1500次，它們也不會嫌煩，如果是人可做不到這一點。
有了junit和其他測試框架，編寫和執行測試變得相當簡單。這就能鼓勵開發人員建立大量測試（往往能更完備地覆蓋各種測試情況），而且會樂於經常執行這些測試（可以更快地幫助開發人員找到bug）。在許多情況下，如果專案中採用了tdd，測試**往往與生產**一樣多！
使用tdd可以帶來許多重要的好處：
提供明確的目標：你很清楚，一旦結束（也就是一旦測試通過），你的工作就完成了（假設你的測試寫得很好）。測試會為**建立乙個自然的邊界，使你把重點集中在當前任務上。一旦測試通過，就有確切的證據證明你的**能工作。相對於人工地測試使用者介面或者比較日誌檔案中的結果，在乙個xunit框架中執行自動化測試，速度要快幾個數量級。大多數xunit測試的執行只需幾微秒，而且大多數採用tdd的人都會一天執行數次測試。在許多開發小組中，將**簽入源**樹之前，**必須成功地通過測試。
提供文件：
你是不是經常遇到看不懂的**？這些**可能沒有任何文件說明，而且開發**的人可能早就走了（或者度假去了）。當然，看到這種**的時間往往也很不合時宜，可能是凌晨3點，也可能有位副總在你旁邊大聲催促著趕快解決昨天的問題，這樣要想花些時間來明白原作者的意圖就更困難了。我們見過一些好的單元測試文件，它們會指出系統要做什麼。測試就像原開發人員留下的記號，可以展示他們的類具體是怎麼工作的。
改善設計：編寫測試能改善設計。測試有助於你從介面的角度思考，測試框架也是**的客戶。測試能讓你考慮得更簡單。如果你確實遵循了「盡量簡單而且行之有效」的原則，就不會寫出篇幅達幾頁的複雜演算法。要測試的**通常依賴性更低，而且相互之間沒有緊密的聯絡，因為這樣測試起來更容易。當然，還有乙個額外的作用，修改起來也會更容易！
鼓勵重構：利用一套健壯的測試集，你能根據需要進行重構。你是不是經常遇到一些不知是否該修改的**？種種顧慮讓你行動遲緩，過於保守，因為你不能保證所做的修改會不會破壞系統。如果有一套好的單元測試集，就能放心地進行重構，同時能保證你的**依然簡潔。
提高速度：編寫這麼多測試會不會使開發速度減慢呢？人們經常會以速度（或開發開銷）作為反對進行tdd和使用xunit框架的理由。所有新的工具都會有學習曲線，但是一旦開發人員適應了他們選擇的框架（通常只需很短的時間），開發速度實際上會加快。乙個完備的單元測試集提供了一種方法對系統完成回歸測試，這說明，增加乙個新特性之後，你不必因為懷疑它會不會破壞原系統而寢食難安。
提供反饋：單元測試還有乙個經常被忽略的優點，即開發的節奏。儘管看上去好像無關緊要，但通過測試之後你會有一種完成任務的成就感！你不會成天地修改**而沒有任何反饋，這種測試—**—測試的方法會鼓勵你動作幅度小一些，通常修改一次**的時間僅幾分鐘而已。這樣你不會一下子看到冒出一大堆的新特性，而只是讓**基一次前進一小步。
從我們的經驗看，測試是會傳染的，你可能會慢慢上癮。一開始，許多開發人員都心存疑慮，但最終幾乎每個開發人員都迷上了執行測試後的綠條。測試第一次「抓住」bug或者增加乙個新特性，只需幾分鐘而不是幾個小時，往往就是在這樣一些時候，開發人員會欣喜地認識到測試確實很有意義。
敏捷測試介紹
敏捷測試介紹 有一次，當開發人員完成當前sprint 任務的 之後，測試人員 開發人員和產品經理一起來瀏覽產品 從頭到尾走一遍，產品經理發現了問題，認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成 但測試人員反對這樣做，我們本來只有5天測試時間，加上這次新做的功能比較多 開發 質...
為什麼要測試先行
在產品的研發過程中，測試一項至關重要。不論是軟體還是硬體。軟體的測試先行，在研發過程中，就做到質量的保證，因為在出現bug的時候，容易定位bug,而且即使是在客戶端出現bug，也能夠輕易的找到bug出現的原因。硬體的測試先行，即保證了研發過程中，方便及時發現出現問題的原因。同時，也為以後的批量生產做...
敏捷開發 敏捷測試
敏捷測試的定義 首先敏捷測試是敏捷的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。在傳統的測試定義上，還需要新增 敏捷測試是遵循敏捷宣言的一種測試實踐 強調從客戶的角度，即使用系統的使用者的角度，來測試系統 重點關注持續迭代的測試新開發的功...