l 步驟
|
u 製品
|
(1)快速新增一個測試用例
|
新的TestCase
|
(2)編譯所有代碼,剛剛寫的那個測試很可能編譯不通過
|
原始的TODO List
|
(3)做盡可能少的改動,讓編譯通過
|
Interface
|
(4)運行所有的測試,發現最新的測試不能編譯通過
|
-(Red Bar)
|
(5)做盡可能少的改動,讓測試通過
|
Implementation
|
(6)運行所有的測試,保證每個都能通過
|
-(Green Bar)
|
(7)重構代碼,以消除重複設計
|
|
- 完工時完工。表明我可以很清楚的看到自己的這段工作已經結束了,而傳統的方式很難知道什麼時候編碼工作結束了。
- 全面正確的認識代碼和利用代碼,而傳統的方式沒有這個機會。
- 爲利用你成果的人提供Sample,無論它是要利用你的源代碼,還是直接重用你提供的組件。
- 開發小組間降低了交流成本,提高了相互信賴程度。
- 避免了過渡設計。
- 系統可以與詳盡的測試集一起發佈,從而對程序的將來版本的修改和擴展提供方便。
- TDD給了我們自信,讓我們今天的問題今天解決,明天的問題明天解決,今天不能解決明天的問題,因爲明天的問題還沒有出現(沒有TestCase),除非有TestCase否則我決不寫任何代碼;明天也不必擔心今天的問題,只要我亮了綠燈。
- 逃避了設計角色。對於一個敏捷的開發小組,每個人都在做設計。
- 大部分時間代碼處在高質量狀態,100%的時間裏成果是可見的。
- 由於可以保證編寫測試和編寫代碼的是相同的程序員,降低了理解代碼所花費的成本。
- 爲減少文檔和代碼之間存在的細微的差別和由這種差別所引入的Bug作出傑出貢獻。
- 在預先設計和緊急設計之間建立一種平衡點,爲你區分哪些設計該事先做、哪些設計該迭代時做提供了一個可靠的判斷依據。
- 事實上提高了開發效率。每一個正在使用TDD並相信TDD的人都會相信這一點,但觀望者則不同,不相信TDD的人甚至堅決反對這一點,這很正常,世界總是這樣。
- 發現比傳統測試方式更多的Bug。
- 使IDE的調試功能失去意義,或者應該說,避免了令人頭痛的調試和節約了調試的時間。
- 總是處在要麼編程要麼重構的狀態下,不會使人抓狂。(兩頂帽子)
- 單元測試非常有趣。
2.更容易在組合體內加入對象部件. 客戶端不必因爲加入了新的對象部件而更改代碼。
public abstract class Equipment
{ private String name; //實價 public abstract double netPrice(); //折扣價格 public abstract double discountPrice(); //增加部件方法 public boolean add(Equipment equipment) { return false; } //刪除部件方法 public boolean remove(Equipment equipment) { return false; } //注意這裏,這裏就提供一種用於訪問組合體類的部件方法。 public Iterator iter() { return null; } public Equipment(final String name) { this.name=name; } } |