單元測試要做多細？

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

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

答案

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.”

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

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

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》里的那個精神分裂者創建了一個連自己都反對的地下組織。呵呵。

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

其它答案

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

第二個答案：值得借鑒

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

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

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

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

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

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

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

我的觀點

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

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

2）軟件開發是一種腦力勞動，是一種知識密集型的工作，就像藝術作品一樣，創作過程和成品是沒有標準答案的。

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

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

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