建站
咨詢
售后
建站咨詢
新聞中心
當(dāng)我***次聽說可以使用框架比如JUnit來進(jìn)行單元測試的時(shí)候，我驚嘆這真是一個(gè)簡單而強(qiáng)大的概念。它取代了隨機(jī)測試，使你可以保存你的測試代碼，并按照需要隨時(shí)運(yùn)行它們。按照我的理解，關(guān)于單元測試并沒有多少產(chǎn)生誤解的可能。但是過去的幾年中，我確實(shí)見過幾種或多或少不太正確的單元測試使用方式。這里按照重要程度，列出5條:
創(chuàng)新互聯(lián)專注于哈巴河網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供哈巴河營銷型網(wǎng)站建設(shè)，哈巴河網(wǎng)站制作、哈巴河網(wǎng)頁設(shè)計(jì)、哈巴河網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)服務(wù)，打造哈巴河網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供哈巴河網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
1. 跟協(xié)作邏輯一起來測試算法。如果跟協(xié)作邏輯代碼分離開來，那么算法邏輯是最容易測試的(參見選擇性單元測試 – 代價(jià)和好處)。否則在你的邏輯被測試之前，你就不得不先進(jìn)行諸如通過任務(wù)隊(duì)列提交一個(gè)任務(wù)之類的工作。 任務(wù)隊(duì)列部分只會(huì)使事情變得復(fù)雜。除非你想測試任務(wù)隊(duì)列本身，否則你就應(yīng)當(dāng)把調(diào)用run方法時(shí)所執(zhí)行的邏輯剝離開來，并對(duì)它進(jìn)行單獨(dú)測試。那樣，不論是編碼還是測試都會(huì)更易于編寫和管理。
2. Mock測試太多。也許單元測試的***好處就是它迫使你編寫能夠獨(dú)立測試的代碼。也就是說，你的代碼會(huì)變得模塊化。當(dāng)你把你要處理的對(duì)象的周圍的一切都模擬了，就沒有什么能迫使你去把各部分分離開來。你會(huì)發(fā)現(xiàn)這樣寫出的代碼，你很難在外圍添加獨(dú)立的部分 – 因?yàn)樗袞|西都糾纏在一起。Bill Wake最近發(fā)推說: ”真是諷刺 – 模擬測試框架越強(qiáng)大，你在改進(jìn)設(shè)計(jì)時(shí)所感受到的壓力就會(huì)越小?！?/p>
3. 不使用斷言。有時(shí)我會(huì)看到一些測試，里面創(chuàng)建了一個(gè)對(duì)象，調(diào)用了一些方法，然后，就沒有然后了。也許它是在循環(huán)里這樣做的，而且在創(chuàng)建和調(diào)用上會(huì)有些差異。但是，卻沒有用斷言來做任何檢查。這就完全失去了意義 – 沒有檢查你的代碼是否按照預(yù)期進(jìn)行工作的。當(dāng)然，代碼是運(yùn)行了，但是僅此而已。如果拋出了一個(gè)異常，我們會(huì)注意到它，但是卻不會(huì)驗(yàn)證其它任何事情。
4. 在測試代碼中遺留print語句。我把這視為手工測試的后遺癥 – 你希望看到對(duì)象的值來判斷它們是否正確。但是所有的檢查都應(yīng)當(dāng)使用斷言來完成。如果單元失敗了，你也能看到它，因?yàn)檫@個(gè)測試也會(huì)失敗。當(dāng)測試通過時(shí)，什么也不應(yīng)當(dāng)打印出來。在編寫測試代碼時(shí)，使用print語句有時(shí)是有用的。但是在需要用print的地方應(yīng)當(dāng)設(shè)置一個(gè)標(biāo)志位，用來在進(jìn)行測試的時(shí)候屏蔽它。
5. 查看日志信息，而不是運(yùn)行結(jié)果。 還好這并不普遍，但是我卻見過一個(gè)非常有能力的開發(fā)人員這么干過。要知道，真正重要的是方法的運(yùn)行結(jié)果，而不是日志中都打印了什么，因?yàn)榧词勾a中有錯(cuò)誤，測試也可能會(huì)通過。好了，說的很明白了。
后面3個(gè)問題都很容易規(guī)避。頭2個(gè)問題則需要付出更多努力，但是會(huì)得到良好分離的代碼。祝測試愉快!
英文原文：5 Unit Testing Mistakes
譯文鏈接：http://www.oschina.net/translate/5-unit-testing-mistakes
文章題目：單元測試?yán)锏?個(gè)錯(cuò)誤
文章源于：http://m.5511xx.com/article/dhdsosd.html
