很意外我選擇了一個自己還算比較感興趣的論文課題TDD（測試驅動開發），而導師讓我挑選的另外一個主題性能測試一不太感興趣，二大概想了想不同的軟件和硬件環境可以搭配出無限種的測試環境，這樣的試驗和研究實在是讓人頭疼，而且根據測不準原理，萬一答辯時老頭跟我較真說：我怎么保證我的測試用例是正確的？我只能回答不能保證；再問我既然測試用例都不正確由它測試出來的程序怎么能是正確的？那時候我只能無奈加無語了。
所以選擇了TDD。經過了一段時間才發現，原來測試雖然復雜尚有可操作的余地，而這個掛著測試之名但不是測試的東西讓我思前想后沒有覓得門路。最開始看來TDD這個名詞的提出，以為內容是驅動程序的測試呢，心想這種東西實在無聊，不知道也罷。看過之后才知，TDD正所謂掛羊頭賣狗肉者，重點不是測試而是開發，其實是開發方法而非測試方法，這里驅動二字實為動詞而非名詞，意指：由測試驅動的、帶動的開發。不知當初誰人最先翻譯成此，實在誤人子弟。
TDD是XP方法學中很重要的一部分，倡導測試先行，由測試驅動代碼開發。沒有代碼測試什么？最初我也是這樣理解。但實際上TDD是一個非常fantastic的東西，加上現在的編譯器十分智能，代碼自然而然運用而生。舉個簡單的例子：
我就寫一個狗叫的程序，具體怎么寫先不管，先寫測試：
Dog xiaobai = new Dog(); //創建一只小狗－小白
assertEquals("wangwang!",xiaobai.bark() ) //判斷小白的吠聲是不是汪汪
好了，測試寫完，run一下，肯定是red bar，同時編譯器會告訴你，沒有發現Dog這個類，很簡單，創建一個，如果你的編譯器夠智能的話你都不用寫 class Dog這句話，點一下錯誤提示的解決方法就可以了。接著，還有錯誤，bay這個方法不存在，編譯器還會提示你：是否創建一個呢？OK，創建一個：public String bark(){ return "wangwang";} 再run一下，OK，測試通過，是green bar，好了，現在看看是不是想要的代碼都出來了？
所以說TDD是個很妙的東西，amazing。然而我的大腦并不妙，還是找不到切入點，TDD這么大的樹林里我還都沒有發現自己要打的那只鳥，更別提逮到它了?？傊耦^苦干，繼續努力了。