單元測試的局限
關于單元測試的一篇好文章，我只翻譯了一段，有興趣的可以看看原文。

譯自：http://www.theserverside.com/blogs/showblog.tss?id=Unitized

考慮一下單元測試的目的和原則：
1。盡量小粒度的“單元”被測試。
2。測試在于其它模塊隔離地情況下獨立地完成。
3。Mocking在隔離的方面作出了強化。
4。代碼和測試都是同一個人完成的。

把上面提到的考慮在一起，意味著單元測試是測試整個代碼中最低層次的部分，每一個部分是和其它部分隔離的。測試和編碼是同一個人完成的。
這種方式的測試正是“我”所說的“low hanging fruit”[可輕易實現的目標 (easy targets)]。它可以捕獲小的問題，也就是可以找到不符合單元測試的要求的單獨的函數或者類。

單元測試是一個好事，提供了對于自己代碼正確性的有價值的反饋。但是“Keep in mind" 它只能得到“low hanging fruit”。在設計上，單元測試被期望“簡單的”、“作為系統中獨立的小部分”。因為這些，在它的本質上（與生俱來的），單元測試沒有考慮系統的“組合”，它只考慮獨立的部分。單元測試從不檢查一個系統中內部的聯絡，從不檢查他們是如何捆綁在一起的。

根據“我”的經驗，系統中如何聯絡和如何捆綁在一起正是系統的復雜度所在。
正是這種“連接”定義了你的設計，如果在一個足夠高的層次上考慮，這種聯系甚至可以理解為系統的架構。
信息是如何在不同的軟件層上和不同的組件之間的流動實實在在的定義了一個應用。
由此看來，單元測試是不會測試一個應用的這些方面的。單元測試忽略了信息是如何在不同的層和不同的組件之間流動的，忽略了類和對象在一個大的架構和設計中如何相互關聯和組合在一起的。
這就意味著單元測試只能在獨立的代碼片斷中捕獲簡單的錯誤，但是對系統的整體的設計或者機構Say nothing。
設計和架構限定了你的系統的性能，內存使用，“端到端”的正確性。[用戶的輸入，到Server處理所使用的，到最后的返回的整個路徑]。所以這些是如何進行聯系的顯示了系統的行為，并且正是在這個范圍中存在著the toughest bug 和 problems，要想讓一切OK，程序員們也要在這個地方苦干不止。
編寫隔離的獨立組件是容易的，把他們粘合在一起是困難的。單元測試只在隔離的在獨立的部分上作判斷，而不是在整體上。

使系統中的一個組件的動作正確相當來說是價值不高的活動。獨立的編寫一個系統的組件不是計算機編程的困難的部分，任何一個個體的小的組件都是容易編寫的。在開發中最難的部分來自于如何把所有的組件捆綁在一起工作。單元測試可以驗證每一個你編寫的獨立組件是不是按照你所想的那樣工作，但是它不能檢查更復雜的“wiring”--“wiring”正是我們的設計，開發和調試絕大部分工數所在。

從上看來，單元測試不會指出“端到端”的處理是否正常，不會關心性能，不會關心內存的使用，不會關心可用性，不會關心代碼是否正是用戶想要的。它也不會捕獲多線程的bug，或者錯誤的理解了外部API或者子系統的使用等等。這些并不意味著單元測試是不好的或者應該避免的，它只是說明單元測試只會給你一個有限的回報。設想我們作為開發人員，我們沒有無限的資源去開發我們的代碼，我們不得不聰明的決定我們要把我們的精力放在那里。我們不得不經常的折衷和決定怎樣做有最好的效果。

在“我”參加的所有開發中。單元測試覆蓋了絕大部分的代碼，但是在以下的方面的努力還差得很遠：
1。應用程序設計的本身。你應該花費更多的時間在你的設計上，采用一種迭代的，真實地方式而不是花費在單元測試上，因為一個好的設計得到的回報比任何數量的單元測試都多。
2。集成測試（Integration Test）。集成測試的測試特征是基于“端到端”的。通過它的設計可以證明你的獨立的組件可以工作在一起。通過一個集成測試，你可以更信賴你的系統按照“端到端”的方式工作，而不是一些獨立的對象。
3。功能測試和回歸測試（Functional Test&Regression Test）。系統不是開發人員想的那樣，而是用戶期望它是什么樣子。更進一步，回歸測試當新的特性被追加或者底層的代碼被改變時，驗證高級別的功能的正確性沒有被改變。
4。非功能測試（Non-function Test)。在可接受的運行需求下，代碼作為整體被運行，請求在可接受的時間范圍內被處理。sever不會因為有3個用戶請求就會memory緊張。等等。

做以上的東西會比單元測試難很多。但是在同樣的投入下會得到更多的回報。