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

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

答案

StackOverflow上，這個(gè)問題的答案是這樣的——

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

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

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

[[93684]]

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.

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

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

其實(shí)我是非常同意Kent的，怎么合適怎么搞，愛怎么測(cè)試就怎么測(cè)試，只要自己和團(tuán)隊(duì)有信心就可以了。沒有必要就一定要寫測(cè)試，一定要測(cè)試先行。

其它答案

八卦完了，我們還是來認(rèn)認(rèn)真真地看看這個(gè)問題中其它的其它答案，因?yàn)檫@個(gè)問題的也是國(guó)人愛問題的問題。

第二個(gè)答案：值得借鑒

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

第三個(gè)答案：給敏捷咨師看的答案

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

第四個(gè)答案：致那些什么都要測(cè)試的人

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

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

我們只可能測(cè)試那些有意義的，確實(shí)要測(cè)試的案例。

我的觀點(diǎn)

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

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

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

3）軟件的質(zhì)量不是測(cè)試出來的，而是設(shè)計(jì)和維護(hù)出來的。就像工匠們?cè)谝稽c(diǎn)一點(diǎn)地同聲雕琢他們的作品一樣。

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

原文鏈接：http://coolshell.cn/articles/8209.html