單元測試要做多細？

這篇文章主要來源是StackOverflow上的一個回答——“How deep are your unit tests?”。一個有13.8K的分的人（John Nolan）問了個關(guān)于TDD的問題，他說——

“TDD需要花時間寫測試，而我們一般多少會寫一些代碼，而第一個測試是測試我的構(gòu)造函數(shù)有沒有把這個類的變量都設(shè)置對了，這會不會太過分了？那么，我們寫單元測試的這個單元的粒度到底是什么樣的？并且，是不是我們的測試測試得多了點？”

答案

StackOverflow上，這個問題的答案是這樣的——

“I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.”

老板為我的代碼付報酬，而不是測試，所以，我對此的價值觀是——測試越少越好，少到你對你的代碼質(zhì)量達到了某種自信（我懷疑這種的自信標(biāo)準(zhǔn)備要高于業(yè)內(nèi)的標(biāo)準(zhǔn)，但這種自信也可能是種自大）。如果我的編碼生涯中不會犯這種典型的錯誤（如：在構(gòu)造函數(shù)中設(shè)了個錯誤的值），那我就不會測試它。我傾向于去做那些有意義的錯誤測試，所以，我對一些比較復(fù)雜的條件邏輯會異常地小心。當(dāng)在一個團隊中，我會非常小心的測試那些會讓團隊容易出錯的代碼。

這個問題并不新鮮，但是這個回答對TDD似乎有一種否定，最亮的是這個問題是由Kent Beck，Kent是XP和TDD的創(chuàng)造者，是敏捷開發(fā)實踐方法的奠基人。以致于還有人調(diào)侃到——

The world does not think that Kent Beck would say this! There are legions of developers dutifully pursuing 100% coverage because they think it is what Kent Beck would do! I have told many that you said, in your XP book, that you don’t always adhere to Test First religiously. But I’m surprised too.

只是要地球人都不會覺得Kent Beck會這么說啊！我們有大堆忠實程序員在追求著100%的代碼測試覆蓋率，因為這些程序員覺得Kent Beck也會這么！我告訴過很多人，你在你的XP的書里說過，你并不總是支持“宗教信仰式的Test First”，但是今天這么說，我還是很驚訝！

后面還有一些不人同意Kent， 我一下子從這個事中想到了《fight club》里的那個精神分裂者創(chuàng)建了一個連自己都反對的地下組織。呵呵。

其實我是非常同意Kent的，怎么合適怎么搞，愛怎么測試就怎么測試，只要自己和團隊有信心就可以了。沒有必要就一定要寫測試，一定要測試先行。

其它答案

八卦完了，我們還是來認認真真地看看這個問題中其它的其它答案，因為這個問題的也是國人愛問題的問題。

第二個答案：值得借鑒

• 開發(fā)過程中，單元測試應(yīng)該來測試那些可能會出錯的地方，或是那些邊界情況。
• 維護過程中，單元測試應(yīng)該跟著我們的bug report來走，每一個bug都應(yīng)該有個UT。于是程序員就會對自己的代碼變更有兩個自信，bug 被 fixed，相同的bug不會再次出現(xiàn)。

第三個答案：給敏捷咨師看的答案

這個答案在說，我們只注意到了TDD中的T，而忽略了第一個D，就是Driven…… bla bla bla… 又這扯這些空洞的東西了，國內(nèi)的各種不學(xué)無術(shù)的敏捷咨詢師最好這一口了。

第四個答案：致那些什么都要測試的人

如果我們需要測試一個像 int square(int x) 這樣的開根函數(shù)，我們需要40億個測試（每個數(shù)都要測試）。

事實上這種情況可能還更糟糕，如果有這樣一個方法 void setX(int newX) 不會更改其它的成員變量，如：obj.z, Obj.y，那么，你是不是還要去測試一下別的變量沒有被改變？

我們只可能測試那些有意義的，確實要測試的案例。

我的觀點

我在《TDD并沒有看上去的那么美》一文中說過我的觀點了，我就不再多說了。我還是把下面這些觀點列出來，供大家思考和討論：

1）我國的教育對我們最大的洗腦不是掩蓋事實，而讓我們習(xí)慣于標(biāo)準(zhǔn)答案，習(xí)慣于教條，從而不會思考！敏捷開發(fā)中的若干東西似乎都成了軟件開發(fā)中對某種標(biāo)準(zhǔn)答案的教條，實在是悲哀！

2）軟件開發(fā)是一種腦力勞動，是一種知識密集型的工作，就像藝術(shù)作品一樣，創(chuàng)作過程和成品是沒有標(biāo)準(zhǔn)答案的。

3）軟件的質(zhì)量不是測試出來的，而是設(shè)計和維護出來的。就像工匠們在一點一點地同聲雕琢他們的作品一樣。

UT的粒度是多少，這個不重要，重要的是你會不會自己思考你的軟件應(yīng)該怎么做，怎么測試。

服務(wù)器租用/服務(wù)器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質(zhì)保障！--億恩科技[ENKJ.COM]