當(dāng)我***次聽說(shuō)可以使用框架比如JUnit來(lái)進(jìn)行單元測(cè)試的時(shí)候，我驚嘆這真是一個(gè)簡(jiǎn)單而強(qiáng)大的概念。它取代了隨機(jī)測(cè)試，使你可以保存你的測(cè)試代碼，并按照需要隨時(shí)運(yùn)行它們。按照我的理解，關(guān)于單元測(cè)試并沒(méi)有多少產(chǎn)生誤解的可能。但是過(guò)去的幾年中，我確實(shí)見(jiàn)過(guò)幾種或多或少不太正確的單元測(cè)試使用方式。這里按照重要程度，列出5條:

1. 跟協(xié)作邏輯一起來(lái)測(cè)試算法。如果跟協(xié)作邏輯代碼分離開來(lái)，那么算法邏輯是最容易測(cè)試的(參見(jiàn)選擇性單元測(cè)試 – 代價(jià)和好處)。否則在你的邏輯被測(cè)試之前，你就不得不先進(jìn)行諸如通過(guò)任務(wù)隊(duì)列提交一個(gè)任務(wù)之類的工作。 任務(wù)隊(duì)列部分只會(huì)使事情變得復(fù)雜。除非你想測(cè)試任務(wù)隊(duì)列本身，否則你就應(yīng)當(dāng)把調(diào)用run方法時(shí)所執(zhí)行的邏輯剝離開來(lái)，并對(duì)它進(jìn)行單獨(dú)測(cè)試。那樣，不論是編碼還是測(cè)試都會(huì)更易于編寫和管理。

2. Mock測(cè)試太多。也許單元測(cè)試的***好處就是它迫使你編寫能夠獨(dú)立測(cè)試的代碼。也就是說(shuō)，你的代碼會(huì)變得模塊化。當(dāng)你把你要處理的對(duì)象的周圍的一切都模擬了，就沒(méi)有什么能迫使你去把各部分分離開來(lái)。你會(huì)發(fā)現(xiàn)這樣寫出的代碼，你很難在外圍添加獨(dú)立的部分 – 因?yàn)樗袞|西都糾纏在一起。Bill Wake最近發(fā)推說(shuō): ”真是諷刺 – 模擬測(cè)試框架越強(qiáng)大，你在改進(jìn)設(shè)計(jì)時(shí)所感受到的壓力就會(huì)越小。”

3. 不使用斷言。有時(shí)我會(huì)看到一些測(cè)試，里面創(chuàng)建了一個(gè)對(duì)象，調(diào)用了一些方法，然后，就沒(méi)有然后了。也許它是在循環(huán)里這樣做的，而且在創(chuàng)建和調(diào)用上會(huì)有些差異。但是，卻沒(méi)有用斷言來(lái)做任何檢查。這就完全失去了意義 – 沒(méi)有檢查你的代碼是否按照預(yù)期進(jìn)行工作的。當(dāng)然，代碼是運(yùn)行了，但是僅此而已。如果拋出了一個(gè)異常，我們會(huì)注意到它，但是卻不會(huì)驗(yàn)證其它任何事情。

4. 在測(cè)試代碼中遺留print語(yǔ)句。我把這視為手工測(cè)試的后遺癥 – 你希望看到對(duì)象的值來(lái)判斷它們是否正確。但是所有的檢查都應(yīng)當(dāng)使用斷言來(lái)完成。如果單元失敗了，你也能看到它，因?yàn)檫@個(gè)測(cè)試也會(huì)失敗。當(dāng)測(cè)試通過(guò)時(shí)，什么也不應(yīng)當(dāng)打印出來(lái)。在編寫測(cè)試代碼時(shí)，使用print語(yǔ)句有時(shí)是有用的。但是在需要用print的地方應(yīng)當(dāng)設(shè)置一個(gè)標(biāo)志位，用來(lái)在進(jìn)行測(cè)試的時(shí)候屏蔽它。

5. 查看日志信息，而不是運(yùn)行結(jié)果。 還好這并不普遍，但是我卻見(jiàn)過(guò)一個(gè)非常有能力的開發(fā)人員這么干過(guò)。要知道，真正重要的是方法的運(yùn)行結(jié)果，而不是日志中都打印了什么，因?yàn)榧词勾a中有錯(cuò)誤，測(cè)試也可能會(huì)通過(guò)。好了，說(shuō)的很明白了。

后面3個(gè)問(wèn)題都很容易規(guī)避。頭2個(gè)問(wèn)題則需要付出更多努力，但是會(huì)得到良好分離的代碼。祝測(cè)試愉快!

英文原文：5 Unit Testing Mistakes

譯文鏈接：http://www.oschina.net/translate/5-unit-testing-mistakes