欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

這篇文章主要來(lái)源是StackOverflow上的一個(gè)回答——“How deep are your unit tests?”。一個(gè)有13.8K的分的人（John Nolan）問(wèn)了個(gè)關(guān)于TDD的問(wèn)題，這個(gè)問(wèn)題并不新鮮，最亮的是這個(gè)問(wèn)題的Best Answer，這個(gè)問(wèn)題是——

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

答案

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

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

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

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

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ì )覺(jué)得Kent Beck會(huì )這么說(shuō)??！我們有大堆程序員在忠實(shí)的追求著(zhù)100%的代碼測試覆蓋率，因為這些程序員覺(jué)得Kent Beck也會(huì )這么干！我告訴過(guò)很多人，你在你的XP的書(shū)里說(shuō)過(guò)，你并不總是支持“宗教信仰式的Test First”，但是今天Kent這么說(shuō)，我還是很驚訝！

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

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

其它答案

八卦完了，我們還是來(lái)認認真真地看看這個(gè)問(wèn)題中其它的其它答案，因為這個(gè)問(wèn)題的也是國人愛(ài)問(wèn)題的問(wèn)題。

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

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

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

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

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

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

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

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

我的觀(guān)點(diǎn)

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

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

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

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

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

（全文完）