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

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

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

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

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

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

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

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

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

做以上的東西會(huì)比單元測(cè)試難很多。但是在同樣的投入下會(huì)得到更多的回報(bào)。