單元測試 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方法的測試會覆蓋到所有的路徑，也包括了私有方法的調用。所以，你也不再需要測試私有方法。
在文中，作者也舉了一些簡單例子說明了用TDD的方式重構出私有方法，以及用測試驅動重構處理遺留代碼的方式，更多細節請閱讀原文。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
