單元測試的規劃方法 單元測試
討論是緣起于我們幾個最近在合作的一個基于Pylons開發的小項目。Pylons本身是一個基于MVC的WEB框架，我們的應用可以簡單地分層為： Controller, Function, Model 這樣三層。Model里都是表結構的定義，沒有什么好測試的；Function部分是主要的功能實現部分，所以我們在這里使用了Python的 unittest框架進行測試；當然，Pylons為Controller的測試提供了一個基于nose的測試環境，不過我們沒用——因為在我們的應用中 Controller只是作為View與Function之間的接口。
但是問題就在這里了，實際開發中發現，某人的Controller代碼居然也有錯誤——具體是誰我就不說了。原因自然是因為我們省略了對Controller的測試，所以這里的錯誤就不能被及時發現，或者說這部分功能代碼沒有被測試所覆蓋到。
令狐在文中說到的第三點——單元測試應該能保證每一個函數的可靠性——應該說是一個完備的測試所要做到的，但是實際上總會有一些取舍。這其中的原因除了一些特別簡單而且基本不會修改的函數可以不必測試以外（這點也要小心，有時越是簡單的函數越可能出錯），另外一部分原因在于一些函數的依賴性，比如對數據庫或網絡這樣的外部資源的依賴。
回到我們那個具體的項目上。
我們當初之所以只對Function部分進行測試，就是因為這部分被我們設計為最主要的功能實現部分，結果現在出現問題——未被測試所覆蓋的部分出錯了。
最圓滿的解決辦法就是再給Controller加一層測試，確保測試的完備。但這樣的話就要多一些編寫測試的工作了。當然，多寫點測試也不是什么壞事，但問題在于我前面已經說了，Controller層很薄，沒有多少代碼，專門為它寫一套測試似乎有點多余。
關于測試的量應該控制在多少，ajoo兄的觀點很值得參考。如果測試代碼的代碼量與被測試代碼差不多，那么這樣的測試似乎就沒有意義了。
好吧，剩下的問題就是：如果減少了測試的代碼量，如何保證覆蓋范圍足夠大？答案是把粒度放得粗一些。
以這個案例來說，我 的觀點是：實現對Controller層的測試，而放棄對Function層的測試——因為Controller層調用了Function層所有功能，也 就是說，測試可以確保同時覆蓋Controller層和Function層。但是代價是失去了測試的準確定位功能，一旦出現測試不通過的情況就無法判斷問 題是出在Controller層還是出在Function層。不過幸好Controller層很薄。
當然，令狐是不贊成我這個觀點的，所以他寫了那么一篇長文章。
其實這樣的事情我是干過的。前兩年為某商業軟件寫過一個他們的專用協議所需的反彈端口代理程序，因為如前面所說，這個程序有對網絡的外部依賴，所以精確的定點測試比較困難，最后我在開發的時候是用了最偷懶的辦法，也就是最粗粒度的測試：
用DUnit寫了一個獨立的測試程序，在其中實現了兩個Mock，分別模擬通訊的兩端與代理程序之間用專用協議連接，只要這兩個Mock之間通過代理的通訊是正確的，就返回測試通過。
最后我就是用這樣的方法把那個程序開發完成的。當然，中間也少不了很多DEBUG LOG的分析處理工作。囧。
總的來說，還是不推薦將測試粒度放得太粗，因為這將失去單元測試的一個很大方面的作用，增加DEBUG的工作量。但是同樣不應該將粒度做得太細，這樣測試就沒有意義了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/