單元測試要作多細

這篇文章主要來源是StackOverflow上的一個回答——「How deep are your unit tests?」。一個有13.8K的分的人（John Nolan）問了個關於TDD的問題，這個問題並不新鮮，最亮的是這個問題的Best Answer，這個問題是——

「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這麼說，我仍是很驚訝！

後面還有一些人不一樣意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的粒度是多少，這個不重要，重要的是你會不會本身思考你的軟件應該怎麼作，怎麼測試。