今天Zoom.Quiet在公司內部分享了對Python測試開發的一些感悟,TDD以及一些開源的Python測試的庫。由於一直在測試一線奮戰,我被做為特邀嘉賓來到現場。由於時間關係,最後我的分享沒有進行。我在這裡說說對Zoom.Quiet演講內容的一些感想吧。
下面的連結是Zoom.Quiet的投影片:
http://py.kingsoft.net/s5/100826-PyTDD/
我打算分享的關於Python GUI測試的投影片:
http://py.kingsoft.net/s5/100826-PyTDD/py-gui-automation/
1. 重點強調了TDD測試先行的做法,以及新需求到來時進行迭代的測試驅動開發過程。
感想:“測試先行”的確是TDD的核心,同時,TDD還有其他一些理念,其實也很值得分享,比如:
- 編寫完測試案例後,用最小化或最精簡的代碼,讓測試案例剛剛好通過( just enough)。然後再繼續補充測試案例,測試案例可能失敗,繼而再修改代碼,讓新的測試案例剛剛好通過。之後一直重複這個過程,直到你再也寫不出一個測試案例,需要修改你的代碼。“just enough code”,我對於這點感觸比較深。一方面因為,我們幾乎沒有可能一次性寫出完全正確讓所有測試案例都通過的代碼,所以必定存在這個迭代的過程。另一方面,能很好的遵循YAGNI(You Are'nt Gonna Need It),避免了過度的設計。
- 測試案例是最好的注釋,同時也是最好的文檔。
2. 分享了大量Python的開源測試載入器或庫。
感想:知道了很多自己不知道的東西,很有意義。
3. “沒有測試案例的持續整合不是持續整合”
感想:說的太好了。同時也要自我反省一下,一直想將測試案例加入持續構建,一直都沒有去做~
4. “測試的本質是什嗎?”
感想:記得一本測試的書講過,測試的本質,就是“想盡一切辦法尋找軟體的缺陷!”。我覺得也是有道理的,所謂的“保證軟體的品質”,並不準確,至少,我可以舉一個反例,進行高效的代碼審查以及招聘最優秀的程式員,同樣也能保證軟體的品質,是不是軟體測試呢?有人說自動化測試不能發現新的缺陷,只能保證已發現的BUG不再重現。其實,只是我們理解的是保證BUG不重現,歸根結底,自動化測試案例一直重複的執行,還是為了找到軟體的缺陷,並且,是存在發現新缺陷的可能的。所以,別想了,軟體測試就是找BUG,直到你再也找不出來為止。(你找不出來並不意味著沒有)。
5. “當你的代碼需要使用過多的Mock對象進行測試時,意味著你的代碼依賴過多,重構它吧”
“不可測的代碼,是需要使用大量的Mock對象的代碼”
“減少依賴,減少Mock對象的使用”
感想:對於這兩個觀點,我有一些不同意見。首先,除非你開發的是類似計算素數或是其他單一性很強的代碼,你不可能不依賴到檔案系統,資料庫,以及網路。而一旦你的測試案例依賴於這三樣東西,你的測試案例就不再屬於單元測試,而是整合測試。除非你只把這部分代碼交給整合測試,不然你必然需要使用Mock對象。
當然,這裡所說的Mock對象也是廣義的概念。嚴格來說,存在諸如:Spy,Fake,Stub,Mock等具有不同意義的東西。雖然只是概念上的理解,在實際測試過程中對測試案例的理解,還是很有意義的。
所以,我覺得,最不可測試的代碼,因為是連Mock的機會都不給的代碼。這樣的代碼我遇到過很多,特別是C++的代碼,我見過的C++程式員,對依賴注入都沒什麼概念。依賴注入,是為了減少對具體對象的依賴,同時,也提供了更好的可測性。允許使用Mock對象進行類比。
關於Mock的爭論其實有很多,我也只是表達一點自己的看法。我也沒有那麼絕對,過度使用Mock,我也是不推薦的。
6. 有人提問:“TDD對可測性的協助有多大?”
我的回答:很大,非常大。當你寫過別人代碼的測試案例的時候你就會知道,假如一個傢伙從來不寫測試案例,他的代碼測試起來會非常痛苦。假如另一個傢伙自己就會寫一些測試案例測試自己的代碼,在寫測試代碼的過程中,其實就已經是在不斷的重構,使得代碼更具可測性的過程。所以,這樣的代碼的可測性會強很多。
7. 關於我自個開發的KWinAuto自動化GUI測試架構
說明:其實這個是我們內部使用的一個GUI測試架構。為了讓名字更好聽,我臨時修改了名字,因為靈感和一些東西來自開源的PyWinAuto,所以,我索性取了個名,叫KWinAuto。這個架構主要是非常簡單的處理了常見的Windows控制項的操作,並且是為我們自己實際測試量身打造的這麼一個庫。離最終開源出來讓大家分享還是有一些距離,所以,就先不放出來了,大家就從我的投影片裡先瞭解一下吧。
除了Zoom.Quiet極力推薦的《Test-driven development》外,我也推薦一本書:《xUnit Test Patterns》
對於我的觀點,歡迎大家拍磚~~