測試驅動開發全功略
PS:找工作告一段落（其實一直不會死心，不到4月底絕不放棄），導師要求開發新的子產品，感覺以前的開發流程太小作坊式了，開發效率十分低下，浪費了很多時間，是以開始學習收集提高開發效率的相關資料了，O(∩_∩)O~！
以下是原文（copy過來格式亂了，可以直接看原部落格！！！）
{關鍵字}
測試驅動開發/Test Driven Development/TDD
測試用例/TestCase/TC
設計/Design
重構/Refactoring
{TDD的目标}
Clean Code That Works
這句話的含義是，事實上我們隻做兩件事情：讓代碼奏效（Work）和讓代碼潔淨（Clean），前者是把事情做對，後者是把事情做好。想想看，其實 我們平時所做的所有工作，除去無用的工作和錯誤的工作以外，真正正确的工作，并且是真正有意義的工作，其實也就隻有兩大類：增加功能和提升設計，而TDD 正是在這個原則上産生的。如果您的工作并非我們想象的這樣，（這意味着您還存在第三類正确有意義的工作，或者您所要做的根本和我們在說的是兩回事），那麼 這告訴我們您并不需要TDD，或者不适用TDD。而如果我們偶然猜對（這對于我來說是偶然，而對于Kent Beck和Martin Fowler這樣的大師來說則是辛勤工作的成果），那麼恭喜您，TDD有可能成為您顯著提升工作效率的一件法寶。請不要将信将疑，若即若離，因為任何一項 新的技術——隻要是從根本上改變人的行為方式的技術——就必然使得相信它的人越來越相信，不信的人越來越不信。這就好比學遊泳，唯一能學會遊泳的途徑就是 親自下去遊，除此之外别無他法。這也好比成功學，即使把卡耐基或希爾博士的書倒背如流也不能擁有積極的心态，可當你以積極的心态去成就了一番事業之後，你 就再也離不開它了。相信我，TDD也是這樣！想試用TDD的人們，請遵循下面的步驟：
編寫TestCase --> 實作TestCase --> 重構 （确定範圍和目标） （增加功能） （提升設計）
[友情提示：靈活模組化中的一個相當重要的實踐被稱為：Prove it With Code，這種想法和TDD不謀而合。]
{TDD的優點}
『充滿吸引力的優點』
- 完工時完工。表明我可以很清楚的看到自己的這段工作已經結束了，而傳統的方式很難知道什麼時候編碼工作結束了。
- 全面正确的認識代碼和利用代碼，而傳統的方式沒有這個機會。
- 為利用你成果的人提供Sample，無論它是要利用你的源代碼，還是直接重用你提供的元件。
- 開發小組間降低了交流成本，提高了互相信賴程度。
- 避免了過渡設計。
- 系統可以與詳盡的測試集一起釋出，進而對程式的将來版本的修改和擴充提供友善。
-
TDD給了我們自信，讓我們今天的問題今天解決，明天的問題明天解決，今天不能解決明天的問題，因為明天的問題還沒有出現(沒有TestCase)，除非有TestCase否則我決不寫任何代碼；明天也不必擔心今天的問題，隻要我亮了綠燈。
『不顯而易見的優點』
- 逃避了設計角色。對于一個靈活的開發小組，每個人都在做設計。
- 大部分時間代碼處在高品質狀态，100％的時間裡成果是可見的。
- 由于可以保證編寫測試和編寫代碼的是相同的程式員，降低了了解代碼所花費的成本。
- 為減少文檔和代碼之間存在的細微的差别和由這種差别所引入的Bug作出傑出貢獻。
-
在預先設計和緊急設計之間建立一種平衡點，為你區分哪些設計該事先做、哪些設計該疊代時做提供了一個可靠的判斷依據。
『有争議的優點』
- 事實上提高了開發效率。每一個正在使用TDD并相信TDD的人都會相信這一點，但觀望者則不同，不相信TDD的人甚至堅決反對這一點，這很正常，世界總是這樣。
- 發現比傳統測試方式更多的Bug。
- 使IDE的調試功能失去意義，或者應該說，避免了令人頭痛的調試和節約了調試的時間。
- 總是處在要麼程式設計要麼重構的狀态下，不會使人抓狂。（兩頂帽子）
- 單元測試非常有趣。
{TDD的步驟}
編寫TestCase --> 實作TestCase --> 重構 （不可運作） （可運作） （重構）
| 步驟 | 制品 |
| （1）快速新增一個測試用例 | 新的TestCase |
| （2）編譯所有代碼，剛剛寫的那個測試很可能編譯不通過 | 原始的TODO List |
| （3）做盡可能少的改動，讓編譯通過 | Interface |
| （4）運作所有的測試，發現最新的測試不能編譯通過 | －(Red Bar) |
| （5）做盡可能少的改動，讓測試通過 | Implementation |
| （6）運作所有的測試，保證每個都能通過 | －(Green Bar) |
| （7）重構代碼，以消除重複設計 | Clean Code That Works |
{FAQ}
[什麼時候重構？]
如果您在軟體公司工作，就意味着您成天都會和想通過重構改善代碼品質的想法打交道，不僅您如此，您的大部 分同僚也都如此。可是，究竟什麼時候該重構，什麼情況下應該重構呢？我相信您和您的同僚可能有很多不同的看法，最常見的答案是“該重構時重構”，“寫不下 去的時候重構”，和“下一次疊代開始之前重構”，或者幹脆就是“最近沒時間，就不重構了，下次有時間的時候重構吧”。正如您已經預見到我想說的——這些想 法都是對重構的誤解。重構不是一種建構軟體的工具，不是一種設計軟體的模式，也不是一個軟體開發過程中的環節，正确了解重構的人應該把重構看成一種書寫代 碼的方式，或習慣，重構時時刻刻有可能發生。在TDD中，除去編寫測試用例和實作測試用例之外的所有工作都是重構，是以，沒有重構任何設計都不能實作。至 于什麼時候重構嘛，還要分開看，有三句話是我的經驗：實作測試用例時重構代碼，完成某個特性時重構設計，産品的重構完成後還要記得重構一下測試用例哦。
[什麼時候設計？]
這個問題比前面一個要難回答的多，實話實說，本人在依照TDD開發軟體的時候也常常被這個問題困擾，總是 覺得有些問題應該在寫測試用例之前定下來，而有些問題應該在新增一個一個測試用例的過程中自然出現，水到渠成。是以，我的建議是，設計的時機應該由開發者 自己把握，不要受到TDD方式的限制，但是，不需要事先确定的事一定不能事先确定，免得捆住了自己的手腳。
[什麼時候增加新的TestCase？]
沒事做的時候。通常我們認為，如果你要增加一個新的功能，那麼先寫一個不能通過的 TestCase；如果你發現了一個bug，那麼先寫一個不能通過的TestCase；如果你現在什麼都沒有，從0開始，請先寫一個不能通過的 TestCase。所有的工作都是從一個TestCase開始。此外，還要注意的是，一些大師要求我們每次隻允許有一個TestCase亮紅燈，在這個 TestCase沒有Green之前不可以寫别的TestCase，這種要求可以适當考慮，但即使有多個TestCase亮紅燈也不要緊，并未違反TDD 的主要精神。
[TestCase該怎麼寫？]
測試用例的編寫實際上就是兩個過程：使用尚不存在的代碼和定義這些代碼的執行結果。是以一個 TestCase也就應該包括兩個部分——場景和斷言。第一次寫TestCase的人會有很大的不适應的感覺，因為你之前所寫的所有東西都是在解決問題， 現在要你提出問題确實不大習慣，不過不用擔心，你正在做正确的事情，而這個世界上最難的事情也不在于如何解決問題，而在于ask the right question！
[TDD能幫助我消除Bug嗎？]
答：不能！千萬不要把“測試”和“除蟲”混為一談！“除蟲”是指程式員通過自己的努力來減 少bug的數量（消除bug這樣的字眼我們還是不要講為好^_^），而“測試”是指程式員書寫産品以外的一段代碼來確定産品能有效工作。雖然TDD所編寫 的測試用例在一定程度上為尋找bug提供了依據，但事實上，按照TDD的方式進行的軟體開發是不可能通過TDD再找到bug的（想想我們前面說的“完工時 完工”），你想啊，當我們的代碼完成的時候，所有的測試用例都亮了綠燈，這時隐藏在代碼中的bug一個都不會露出馬腳來。
但是，如果要問“測試”和“除蟲”之間有什麼聯系，我相信還是有很多話可以講的，比如TDD事實上減少了bug的數量，把查找bug戰役的關注點從 全線戰場提升到代碼戰場以上。還有，bug的最可怕之處不在于隐藏之深，而在于滿天遍野。如果你發現了一個使用者很不容易才能發現的bug，那麼不一定對工 作做出了什麼傑出貢獻，但是如果你發現一段代碼中，bug的密度或離散程度過高，那麼恭喜你，你應該抛棄并重寫這段代碼了。TDD避免了這種情況，是以将 尋找bug的工作降低到了一個新的低度。
[我該為一個Feature編寫TestCase還是為一個類編寫TestCase？]
初學者常問的問題。雖然我們從TDD 的說明書上看到應該為一個特性編寫相應的TestCase，但為什麼著名的TDD大師所寫的TestCase都是和類/方法一一對應的呢？為了解釋這個問 題，我和我的同僚們都做了很多試驗，最後我們得到了一個結論，雖然我不知道是否正确，但是如果您沒有答案，可以姑且相信我們。
我們的研究結果表明，通常在一個特性的開發開始時，我們針對特性編寫測試用例，如果您發現這個特性無法用TestCase表達，那麼請将這個特性細 分，直至您可以為手上的特性寫出TestCase為止。從這裡開始是最安全的，它不會導緻任何設計上重大的失誤。但是，随着您不斷的重構代碼，不斷的重構 TestCase，不斷的依據TDD的思想做下去，最後當産品伴随測試用例集一起釋出的時候，您就會不經意的發現經過重構以後的測試用例很可能是和産品中 的類/方法一一對應的。
[什麼時候應該将全部測試都運作一遍？]
Good Question！大師們要求我們每次重構之後都要完整的運作一遍測試用例。這個要求可以了解，因為重構很可能會改變整個代碼的結構或設計，進而導緻不可 預見的後果，但是如果我正在開發的是一個ERP怎麼辦？運作一遍完整的測試用例可能将花費數個小時，況且現在很多重構都是由工具做到的，這個要求的可行性 和前提條件都有所動搖。是以我認為原則上你可以挑幾個你覺得可能受到本次重構影響的TestCase去run，但是如果運作整個測試包隻要花費數秒的時 間，那麼不介意你按大師的要求去做。
[什麼時候改進一個TestCase？]
增加的測試用例或重構以後的代碼導緻了原來的TestCase的失去了效果，變得無 意義，甚至可能導緻錯誤的結果，這時是改進TestCase的最好時機。但是有時你會發現，這樣做僅僅導緻了原來的TestCase在設計上是臃腫的，或 者是備援的，這都不要緊，隻要它沒有失效，你仍然不用去改進它。記住，TestCase不是你的産品，它不要好看，也不要怎麼太科學，甚至沒有性能要求， 它隻要能完成它的使命就可以了——這也證明了我們後面所說的“用Ctrl-C/Ctrl-V編寫測試用例”的可行性。
但是，美國人的想法其實跟我們還是不太一樣，拿托尼巴贊的MindMap來說吧，其實畫MindMap隻是為了表現自己的思路，或記憶某些重要的事 情，但托尼卻建議大家把MindMap畫成一件藝術品，甚至還有很多藝術家把自己畫的抽象派MindMap拿出來幫助托尼做宣傳。同樣，大師們也要求我們 把TestCase寫的跟代碼一樣品質精良，可我想說的是，現在國内有幾個公司能把産品的代碼寫的精良？？還是一步一步慢慢來吧。
[為什麼原來通過的測試用例現在不能通過了？]
這是一個警報，Red Alert！它可能表達了兩層意思——都不是什麼好意思——1）你剛剛進行的重構可能失敗了，或存在一些錯誤未被發現，至少重構的結果和原來的代碼不等價 了。2）你剛剛增加的TestCase所表達的意思跟前面已經有的TestCase相沖突，也就是說，新增的功能違背了已有的設計，這種情況大部分可能是 之前的設計錯了。但無論哪錯了，無論是那層意思，想找到這個問題的根源都比TDD的正常工作要難。
[我怎麼知道那裡該有一個方法還是該有一個類？]
這個問題也是常常出現在我的腦海中，無論你是第一次接觸TDD或者已經成為 TDD專家，這個問題都會纏繞着你不放。不過問題的答案可以參考前面的“什麼時候設計”一節，答案不是唯一的。其實多數時候你不必考慮未來，今天隻做今天 的事，隻要有重構工具，從方法到類和從類到方法都很容易。
[我要寫一個TestCase，可是不知道從哪裡開始？]
從最重要的事開始，what matters most？從腳下開始，從手頭上的工作開始，從眼前的事開始。從一個沒有UI的核心特性開始，從算法開始，或者從最有可能耽誤時間的子產品開始，從一個最嚴 重的bug開始。這是TDD主義者和鼠目寸光者的一個共同點，不同點是前者早已成竹在胸。
[為什麼我的測試總是看起來有點愚蠢？]
哦？是嗎？來，握個手，我的也是！不必擔心這一點，事實上，大師們給的例子也相當愚 蠢，比如一個極端的例子是要寫一個兩個int變量相加的方法，大師先斷言2+3=5，再斷言5+5=10，難道這些代碼不是很愚蠢嗎？其實這隻是一個極端 的例子，當你初次接觸TDD時，寫這樣的代碼沒什麼不好，以後當你熟練時就會發現這樣寫沒必要了，要記住，謙虛是通往TDD的必經之路！從經典開發方法轉 向TDD就像從面向過程轉向面向對象一樣困難，你可能什麼都懂，但你寫出來的類沒有一個純OO的！我的同僚還告訴我真正的太極拳，其速度是很快的，不比任 何一個快拳要慢，但是初學者（通常是指學習太極拳的前10年）太不容易把每個姿勢都做對，是以隻能慢慢來。
[什麼場合不适用TDD？]
問的好，确實有很多場合不适合使用TDD。比如對軟體品質要求極高的軍事或科研産品——神州六号，人命關天的軟體——醫療裝置，等等，再比如設計很重要必須提前做好的軟體，這些都不适合TDD，但是不适合TDD不代表不能寫TestCase，隻是作用不同，地位不同罷了。
{Best Practise}
[微笑面對編譯錯誤]
學生時代最害怕的就是編譯錯誤，編譯錯誤可能會被老師視為上課不認真聽課的證據，或者同學間互相嘲笑的 砝碼。甚至離開學校很多年的老程式員依然害怕它就像害怕遲到一樣，潛意識裡似乎編譯錯誤極有可能和工資挂鈎（或者和智商挂鈎，反正都不是什麼好事）。其 實，隻要送出到版本管理的代碼沒有編譯錯誤就可以了，不要擔心自己手上的代碼的編譯錯誤，通常，編譯錯誤都集中在下面三個方面：
（1）你的代碼存在低級錯誤
（2）由于某些Interface的實作尚不存在，是以被測試代碼無法編譯
（3）由于某些代碼尚不存在，是以測試代碼無法編譯
請注意第二點與第三點完全不同，前者表明設計已存在，而實作不存在導緻的編譯錯誤；後者則指僅有TestCase而其它什麼都沒有的情況，設計和實作都不存在，沒有Interface也沒有Implementation。
另外，編譯器還有一個優點，那就是以最靈活的身手告訴你，你的代碼中有那些錯誤。當然如果你擁有Eclipse這樣可以及時提示編譯錯誤的IDE，就不需要這樣的功能了。
[重視你的計劃清單]
在非TDD的情況下，尤其是傳統的瀑布模型的情況下，程式員不會不知道該做什麼，事實上，總是有設計或 者别的什麼制品在引導程式員開發。但是在TDD的情況下，這種優勢沒有了，是以一個計劃清單對你來說十分重要，因為你必須自己發現該做什麼。不同性格的人 對于這一點會有不同的反應，我相信平時做事沒什麼計劃要依靠别人安排的人（所謂将才）可能略有不适應，不過不要緊，Tasks和Calendar（又稱效 率手冊）早已成為現代上班族的必備工具了；而平時工作生活就很有計劃性的人，比如我:)，就會更喜歡這種自己可以掌控Plan的方式了。
[廢黜每日代碼品質檢查]
如果我沒有記錯的話，PSP對于個人代碼檢查的要求是蠻嚴格的，而同樣是在針對個人的問題上， TDD卻建議你廢黜每日代碼品質檢查，别起疑心，因為你總是在做TestCase要求你做的事情，并且總是有辦法（自動的）檢查代碼有沒有做到這些事情 ——紅燈停綠燈行，是以每日代碼檢查的時間可能被節省，對于一個嚴格的PSP實踐者來說，這個成本還是很可觀的！
此外，對于每日代碼品質檢查的另一個好處，就是幫助你認識自己的代碼，全面的從宏觀、微觀、各個角度審視自己的成果，現在，當你依照TDD做事時，這個優點也不需要了，還記得前面說的TDD的第二個優點嗎，因為你已經全面的使用了一遍你的代碼，這完全可以達到目的。
但是，問題往往也并不那麼簡單，現在有沒有人能告訴我，我如何全面審視我所寫的測試用例呢？别忘了，它們也是以代碼的形式存在的哦。呵呵，但願這個 問題沒有把你吓到，因為我相信到目前為止，它還不是瓶頸問題，況且在編寫産品代碼的時候你還是會自主的發現很多測試代碼上的沒考慮到的地方，可以就此修改 一下。道理就是如此，世界上沒有任何方法能代替你思考的過程，是以也沒有任何方法能阻止你犯錯誤，TDD僅能讓你更容易發現這些錯誤而已。
[如果無法完成一個大的測試，就從最小的開始]
如果我無法開始怎麼辦，教科書上有個很好的例子：我要寫一個電影清單的類，我 不知道如何下手，如何寫測試用例，不要緊，首先想象靜态的結果，如果我的電影清單剛剛建立呢，那麼它應該是空的，OK，就寫這個斷言吧，斷言一個剛剛初始 化的電影清單是空的。這不是愚蠢，這是細節，奧運會五項全能的金牌得主瑪麗蓮·金是這樣說的：“成功人士的共同點在于……如果目标不夠清晰，他們會首先做 通往成功道路上的每一個細小步驟……”。
[嘗試編寫自己的xUnit]
Kent Beck建議大家每當接觸一個新的語言或開發平台的時候，就自己寫這個語言或平台的xUnit，其實幾乎所有常用的語言和平台都已經有了自己的 xUnit，而且都是大同小異，但是為什麼大師給出了這樣的建議呢。其實Kent Beck的意思是說通過這樣的方式你可以很快的了解這個語言或平台的特性，而且xUnit确實很簡單，隻要知道原理很快就能寫出來。這對于那些喜歡自己寫 底層代碼的人，或者喜歡控制力的人而言是個好消息。
[善于使用Ctrl-C/Ctrl-V來編寫TestCase]
不必擔心TestCase會有代碼備援的問題，讓它備援好了。
[永遠都是功能First，改進可以稍後進行]
上面這個标題還可以改成另外一句話：避免過渡設計！
[淘汰陳舊的用例]
舍不得孩子套不着狼。不要可惜陳舊的用例，因為它們可能從概念上已經是錯誤的了，或僅僅會得出錯誤的結果，或者在某次重構之後失去了意義。當然也不一定非要删除它們，從TestSuite中除去（JUnit）或加上Ignored（NUnit）标簽也是一個好辦法。
[用TestCase做試驗]
如果你在開始某個特性或産品的開發之前對某個領域不太熟悉或一無所知，或者對自己在該領域裡的 能力一無所知，那麼你一定會選擇做試驗，在有單元測試作工具的情況下，建議你用TestCase做試驗，這看起來就像你在寫一個驗證功能是否實作的 TestCase一樣，而事實上也一樣，隻不過你所驗證的不是代碼本身，而是這些代碼所依賴的環境。
[TestCase之間應該盡量獨立]
保證單獨運作一個TestCase是有意義的。
[不僅測試必須要通過的代碼，還要測試必須不能通過的代碼]
這是一個小技巧，也是不同于設計思路的東西。像越界的值或者亂 碼，或者類型不符的變量，這些輸入都可能會導緻某個異常的抛出，或者導緻一個标示“illegal parameters”的傳回值，這兩種情況你都應該測試。當然我們無法枚舉所有錯誤的輸入或外部環境，這就像我們無法枚舉所有正确的輸入和外部環境一 樣，隻要TestCase能說明問題就可以了。
[編寫代碼的第一步，是在TestCase中用Ctrl-C]
這是一個進階技巧，呃，是的，我是這個意思，我不是說這個技巧 難以掌握，而是說這個技巧當且僅當你已經是一個TDD高手時，你才能體會到它的魅力。多次使用TDD的人都有這樣的體會，既然我的TestCase已經寫 的很好了，很能說明問題，為什麼我的代碼不能從TestCase拷貝一些東西來呢。當然，這要求你的TestCase已經具有很好的表達能力，比如斷言f (5)=125的方式顯然沒有斷言f(5)=5^(5-2)表達更多的内容。
[測試用例包應該盡量設計成可以自動運作的]
如果産品是需要傳遞源代碼的，那我們應該允許使用者對代碼進行修改或擴充後在自己 的環境下run整個測試用例包。既然通常情況下的産品是可以自動運作的，那為什麼同樣作為傳遞使用者的制品，測試用例包就不是自動運作的呢？即使産品不需要 傳遞源代碼，測試用例包也應該設計成可以自動運作的，這為測試部門或下一版本的開發人員提供了極大的便利。
[隻亮一盞紅燈]
大師的建議，前面已經提到了，僅僅是建議。
[用TestCase描述你發現的bug]
如果你在另一個部門的同僚使用了你的代碼，并且，他發現了一個bug，你猜他會怎 麼做？他會立即走到你的工位邊上，大聲斥責說：“你有bug！”嗎？如果他膽敢這樣對你，對不起，你一定要冷靜下來，不要當面回罵他，相反你可以微微一 笑，然後心平氣和的對他說：“哦，是嗎？那麼好吧，給我一個TestCase證明一下。”現在局勢已經倒向你這一邊了，如果他還沒有準備好回答你這緻命的 一擊，我猜他會感到非常羞愧，并在内心責怪自己太莽撞。事實上，如果他的TestCase沒有過多的要求你的代碼（而是按你們事前的契約），并且亮了紅 燈，那麼就可以确定是你的bug，反之，對方則無理了。用TestCase描述bug的另一個好處是，不會因為以後的修改而再次暴露這個bug，它已經成 為你釋出每一個版本之前所必須檢查的内容了。
{關于單元測試}
單元測試的目标是
Keep the bar green to keep the code clean
這句話的含義是，事實上我們隻做兩件事情：讓代碼奏效（Keep the bar green）和讓代碼潔淨（Keep the code clean），前者是把事情做對，後者是把事情做好，兩者既是TDD中的兩頂帽子，又是xUnit架構中的因果關系。
單元測試作為軟體測試的一個類别，并非是xUnit架構創造的，而是很早就有了。但是xUnit架構使得單元測試變得直接、簡單、高效和規範，這也 是單元測試最近幾年飛速發展成為衡量一個開發工具和環境的主要名額之一的原因。正如Martin Fowler所說：“軟體工程有史以來從沒有如此衆多的人大大收益于如此簡單的代碼！”而且多數語言和平台的xUnit架構都是大同小異，有的僅是語言不 同，其中最有代表性的是JUnit和NUnit，後者是前者的創新和擴充。一個單元測試架構xUnit應該：1）使每個TestCase獨立運作；2）使 每個TestCase可以獨立檢測和報告錯誤；3）易于在每次運作之前選擇TestCase。下面是我枚舉出的xUnit架構的概念，這些概念構成了目前 業界單元測試理論和工具的核心：
[測試方法/TestMethod]
測試的最小機關，直接表示為代碼。
[測試用例/TestCase]
由多個測試方法組成，是一個完整的對象，是很多TestRunner執行的最小機關。
[測試容器/TestSuite]
由多個測試用例構成，意在把相同含義的測試用例手動安排在一起，TestSuite可以呈樹狀結構因而便于管理。在實作時，TestSuite形式上往往也是一個TestCase或TestFixture。
[斷言/Assertion]
斷言一般有三類，分别是比較斷言（如assertEquals），條件斷言（如isTrue），和斷言工具（如fail）。
[測試裝置/TestFixture]
為每個測試用例安排一個SetUp方法和一個TearDown方法，前者用于在執行該測試用例或該用例中的每個測試方法前調用以初始化某些内容，後者在執行該測試用例或該用例中的每個方法之後調用，通常用來消除測試對系統所做的修改。
[期望異常/Expected Exception]
期望該測試方法抛出某種指定的異常，作為一個“斷言”内容，同時也防止因為合情合理的異常而意外的終止了測試過程。
[種類/Category]
為測試用例分類，實際使用時一般有TestSuite就不再使用Category，有Category就不再使用TestSuite。
[忽略/Ignored]
設定該測試用例或測試方法被忽略，也就是不執行的意思。有些被抛棄的TestCase不願删除，可以定為Ignored。
[測試執行器/TestRunner]
執行測試的工具，表示以何種方式執行測試，别誤會，這可不是在代碼中規定的，完全是與測試内容無關的行為。比如文本方式，AWT方式，swing方式，或者Eclipse的一個視圖等等。
{執行個體：Fibonacci數列}
下面的Sample展示TDDer是如何編寫一個旨在産生Fibonacci數列的方法。
（1）首先寫一個TC，斷言fib(1) = 1;fib(2) = 1;這表示該數列的第一個元素和第二個元素都是1。
public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
}
（2）上面這段代碼不能編譯通過，Great！——是的，我是說Great！當然，如果你正在用的是Eclipse那你不需要編譯，Eclipse 會告訴你不存在fib方法，單擊mark會問你要不要建立一個fib方法，Oh，當然！為了讓上面那個TC能通過，我們這樣寫：
public int fib( int n ) {
return 1;
}
（3）現在那個TC亮了綠燈，wow！應該慶祝一下了。接下來要增加TC的難度了，測第三個元素。
public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
assertEquals(2, fib(3));
}
不過這樣寫還不太好看，不如這樣寫：
public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
assertEquals(fib(1)+fib(2), fib(3));
}
（4）新增加的斷言導緻了紅燈，為了扭轉這一局勢我們這樣修改fib方法，其中部分代碼是從上面的代碼中Ctrl-C/Ctrl-V來的：
public int fib( int n ) {
if ( n == 3 ) return fib(1)+fib(2);
return 1;
}
（5）天哪，這真是個賤人寫的代碼！是啊，不是嗎？因為TC就是産品的藍本，産品隻要恰好滿足TC就ok。是以事情發展到這個地步不是fib方法的錯，而是TC的錯，于是TC還要進一步要求：
public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
assertEquals(fib(1)+fib(2), fib(3));
assertEquals(fib(2)+fib(3), fib(4));
}
（6）上有政策下有對策。
public int fib( int n ) {
if ( n == 3 ) return fib(1)+fib(2);
if ( n == 4 ) return fib(2)+fib(3);
return 1;
}
（7）好了，不玩了。現在已經不是賤不賤的問題了，現在的問題是代碼出現了備援，是以我們要做的是——重構：
public int fib( int n ) {
if ( n == 1 || n == 2 ） return 1;
else return fib( n - 1 ) + fib( n - 2 );
}
（8）好，現在你已經fib方法已經寫完了嗎？錯了，一個危險的錯誤，你忘了錯誤的輸入了。我們令0表示Fibonacci中沒有這一項。
public void testFab() {
assertEquals(1, fib(1));
assertEquals(1, fib(2));
assertEquals(fib(1)+fib(2), fib(3));
assertEquals(fib(2)+fib(3), fib(4));
assertEquals(0, fib(0));
assertEquals(0, fib(-1));
}
then change the method fib to make the bar grean：
public int fib( int n ) {
if ( n <= 0 ) return 0;
if ( n == 1 || n == 2 ） return 1;
else return fib( n - 1 ) + fib( n - 2 );
}
（9）下班前最後一件事情，把TC也重構一下：
public void testFab() {
int cases[][] = {
{0, 0}, {-1, 0}, //the wrong parameters
{1, 1}, {2, 1}}; //the first 2 elements
for (int i = 0; i < cases.length; i++)
assertEquals( cases[i][1], fib(cases[i][0]) );
//the rest elements
for (int i = 3; i < 20; i++)
assertEquals(fib(i-1)+fib(i-2), fib(i));
}
（10）打完收工。
{關于本文的寫作}
在本文的寫作過程中，作者也用到了TDD的思維，事實上作者先構思要寫一篇什麼樣的文章，然後寫出這篇文章應該滿足的幾個要求，包括功能的要求（要 寫些什麼）和性能的要求（可讀性如何）和品質的要求（文字的要求），這些要求起初是一個也達不到的（因為正文還一個字沒有），在這種情況下作者的文章無法 編譯通過，為了達到這些要求，作者不停的寫啊寫啊，終于在花盡了兩個月的心血之後完成了當初既定的所有要求（make the bar green），随後作者整理了一下文章的結構（重構），在滿意的送出給了Blog系統之後，作者穿上了一件綠色的汗衫，趴在地上，學了兩聲青蛙 叫。。。。。。。^_^
{後記：Martin Fowler在中國}
從本文正式完成到發表的幾個小時裡，我偶然讀到了Martin Fowler先生北京訪談錄，其間提到了很多對測試驅動開發的看法，摘抄在此：
Martin Fowler：當然（值得花一半的時間來寫單元測試）！因為單元測試能夠使你更快的完成工作。無數次的實踐已經證明這一點。你的時間越是緊張，就越要寫單元測試，它看上去慢，但實際上能夠幫助你更快、更舒服地達到目的。
Martin Fowler：什麼叫重要？什麼叫不重要？這是需要逐漸認識的，不是想當然的。我為絕大多數的子產品寫單元測試，是有點煩人，但是當你意識到這工作的價值時，你會欣然的。
Martin Fowler：對全世界的程式員我都是那麼幾條建議：……第二，學習測試驅動開發，這種新的方法會改變你對于軟體開發的看法。……
——《程式員》，2005年7月刊
{鳴謝}
fhawk
Dennis Chen
般若菩提
Kent Beck
Martin Fowler
c2.com
（轉載本文需注明出處：Brian Sun @ 爬樹的泡泡[http://www.blogjava.net/briansun]）
轉載于:https://www.cnblogs.com/kira2will/p/4122873.html
![Web Service開發實戰[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)