如果單元測試的結果是錯的,那一定是程序出了問題,而且這個錯誤一定是可以重復的。
問:如果用隨機數以增加測試的真實性,好么?
答:一般情況下不好,如果某個隨機數導致程序出錯,但是下一次運行又不能重復這一錯誤,于事無補。要注意我們還是要用隨機數等辦法“增加測試的真實性”,但是不是在單元測試中。單元測試不能解決所有問題,所以也不必期望它會發現所有的缺陷。
1.4.2.6 獨立性,單元測試的運行/通過/失敗不依賴于別的測試,可以人為構造數據,以保持單元測試的獨立性。
程序中的各個模塊都是互相依賴的,否則它們就不會出現在一個程序中。一般情況下,單元測試中的模塊可以直接引用其它的模塊,并期待其它的模塊能返回正確的結果。
如果其它的模塊很不穩定,或者其他模塊運行比較費時(如進行網絡操作),而且對于本模塊的正確性并不起關鍵的作用。這時可以人為地構造數據以保證這個單元測試的獨立性。
New Object
New user
Get user permission // go thru the server to get the correct permission, you can also mock the permission object.
Object.Test(user)
1.4.2.7 單元測試應該覆蓋所有代碼路徑,包括錯誤處理路徑,為了保證單元測試的代碼覆蓋率,單元測試必須測試公開的和私有的函數/方法。
單元測試必須覆蓋所測單元的所有代碼路徑。
問:!這樣豈不是要寫很多啰里啰唆的測試方法?
答:對,因為程序中很多缺陷都是從這些啰里啰唆的錯誤處理中產生的。如果你的模塊中某個錯誤處理路徑很難到達,那你也許要想想是否可以把這個錯誤處理拿掉。
[大栓:這對于那些愛寫復雜代碼的人是一個很好的懲罰,不對,是一個很好的鍛煉。]
[阿超:對,把單元測試的責任和代碼作者綁定在一起后,代碼作者就能更真切地體會到復雜代碼的副作用,因為驗證復雜代碼的正確性要困難得多。要注意的一點是:100%的代碼覆蓋率并不等同于100%的正確性,請看下列例子]
e.g. didn’t check return value.
e.g. memory leak
1.4.2.8 單元測試應該集成到自動測試的框架中
另一個重要的措施是要把單元測試自動化,這樣每個人都能很容易地運行,并且單元測試每天都可以運行。每個人都可以隨時在自己機器上運行。團隊一般是在每日構建中運行單元測試,這樣每個單元測試的錯誤就能及時發現并得到修改。
1.4.2.9 單元測試必須和產品代碼一起保存和維護
單元測試必須和代碼一起進行版本維護。如果不是這樣,過了一陣,代碼和單元測試就會出現不一致,而且所有代碼的作者要花時間來確認哪些是程序出現的錯誤,哪些是由于單元測試更新滯后造成的錯誤。。。這樣就失去了單元測試的意義,同時又給大家增加了負擔,折騰多次以后,大家就會覺得維護單元測試是一件很費時費力的事。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
延伸閱讀