軟件測試中單元測試VS私有方法

         軟件測試中單元測試VS私有方法  軟件測試

　　前幾天，Naresh Jain在Managed Chaos上發了篇博客，總結了一些測試中的bad smell。例如：

　　● 一個方法中有太多test case——被測試的方法做了太多事情。

　　● 太多的setup/teardown——表示被測試類的耦合性太高。

　　● 改變一個地方，多處測試受影響——也許是測試的設計問題，也許是實現代碼中有過多依賴。

　　● 測試上下文中有太多依賴——設計中的耦合性太高。

　　● 測試運行速度緩慢——表示你的單元測試也許在使用外部系統，例如網絡、數據庫、文件系統等等。通常也意味著被測試類有過多的職責。

　　……

　　里面還有一條：

　　為了測試的目的，把成員變量或者方法的訪問權限變成protected或者public——可能是因為測試代碼跟被測試的代碼耦合太高，也可能是本來私有的東西有太多行為，這種情況下應該考慮把它抽出來作為獨立的對象。

　　怎么為私有方法寫單元測試?這個難題由來已久了。

　　有人會選擇跳過私有方法，有人會選擇去掉private限定符;跳過私有方法自然不是良策，但提升訪問權限也會破壞封裝，在Naresh Jain看來也算得上是bad smell，那怎么解決才好?

　　Naresh Jain對此語焉不詳，不過還好，Agile Tips在08年11月有一篇文章介紹了怎么測試私有方法。

　　文末作者說道：

　　應該為私有方法添加測試么?

　　我的答案是，在成功的用了TDD或者測試驅動重構(Test-Driven Refactoring)以后，你的代碼中就不會出現針對私有方法的測試。

　　如果你用TDD編寫全新的代碼，在沒有測試之前是沒有功能的。私有方法是到了重構那一步的最后才會出現。把代碼轉移到私有方法中的這個過程，已經被先前寫過的測試覆蓋到了。所以，如果你成功了用了TDD，代碼中就不會出現針對私有方法的測試。

　　如果你在改善遺留代碼，你就該使用測試驅動重構。這樣的話，可能會臨時針對私有方法寫一些測試。但是，隨著測試覆蓋率的增加，那些public方法的測試會覆蓋到所有的路徑，也包括了私有方法的調用。所以，你也不再需要測試私有方法。

原文轉自：http://www.kjueaiud.com