在TDD中煎熬了已有一陣子了,所謂吃得苦中苦,方為人上人.回首這段旅程,需要總結的東西很多,我只理理曾經出現在腦海中的疑問,并提供本人的對該問題的理解.以后隨時補充.
☆寫測試的時間比寫代碼的時間還多?
在有些情況下的確如此,但是不要太擔心.為什么呢? 根據我的體會:
1.有了測試,你會少寫很多本來不需要(初看起來應該是有用)的代碼
2.寫測試的過程就是在解決問題的過程,因此你會比較容易,盡早地明白你到底應該做什么.這樣在寫代碼時,就能節省時間
3.對重構幫助很大.有了測試,你才能放心大膽的進行重構.
4.長遠來看,因為TDD會促進你寫出好的代碼,并且你會經常的重構,因此會降低維護代價
☆需要為每個方法編寫測試嗎?
當然不需要.我們所寫的測試必須是針對接口方法的.一般認為處理業務邏輯的方法,以及領域模型對象的關鍵行為是必須進行測試. 其它的一些方法需要自己把握,當然這需要經驗.
我現在只是一個新手,沒有啥經驗.我判斷某個方法是否需要測試,依據有兩條:
1.是否滿足我上面列出的必須測試條件
2.是否值的測試,這一條主要是心理因素,例如對某個方法感覺心里沒底,那就先編寫測試.
☆TDD是一種測試新技術嗎?
當然不是,TDD根本就不是一項測試技術.它是一種新的開發方式,只是借助測試而已.
☆項目一開始沒有采用TDD,在項目中期再引入TDD,可行嗎?
一般來說不推薦在項目中期再引入TDD,這是由于TDD內在特性決定的.
1.TDD是一種新的開發方法,在開發過程中就需要你轉變思想,需要在實踐不斷完善自己,而且它本身就具有一個較陡學習的坡度,這一點在很多文章中都提到過.因此在項目中期引入TDD,會立即拖延項目進展,對項目本身幫助也不會太大.
2.TDD在你開始寫測試時,會驅動你對問題進行思考,然后持續進行功能增強和重構.在項目中期,如果你編寫一個測試,這時你需要項目早期的一個組件,但是這個組件并沒有滿足你的測試(因為根本就沒有測試).現在因為該組件有問題,測試通不過.如果這時你再為該組件編寫單元測試,就失去了測試驅動開發的優勢了,此時TDD的效果就大打折扣了.
當然,在沒有項目壓力的情況下,引入TDD是沒有任何問題的.不過我還是推薦在項目開始就引入TDD是最佳選擇.
☆為也存在的組件補充單元測試值得嗎?
在上一問題的第二點原因中已經提到過,感覺不值得.在這種情況下,用一般的方法測試一下即可,比如java的main()方法.
☆TDD編寫的測試案例是比較復雜的嗎?
在TDD中,測試是一步一步演化的,需要你一直保持簡單設計的理念,因此,一般測試案例是比較清晰的.如果發現你的測試非常復雜,應該是你沒有抓住問題的重點或者沒有掌握正確,有效的方法.