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

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

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

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

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

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

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

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

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

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