99在线精品视频在线观看,国产午夜福利在线看,福利社影院

避免致命的五大單元測試弊端

原創(chuàng)|行業(yè)資訊|編輯：龔雪|2014-10-20 09:26:15.000|閱讀 321 次

概述：單元測試的需求越來越大，開發(fā)者或開發(fā)者團(tuán)隊的工作壓力或技術(shù)局限，導(dǎo)致單元測試漏洞頻發(fā)。

世界著名開發(fā)測試公司PRQA與Parasoft或多或少的讓開發(fā)者知道了單元測試框架的概念。相對于單元測試的需求，開發(fā)者暴露出來的測試問題，總結(jié)下來可以歸結(jié)五大漏洞。

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

2. Mock測試太多。也許單元測試的最大好處就是它迫使你編寫能夠獨立測試的代碼。也就是說，你的代碼會變得模塊化。當(dāng)你把你要處理的對象的周圍的一切都模擬了，就沒有什么能迫使你去把各部分分離開來。你會發(fā)現(xiàn)這樣寫出的代碼，你很難在外圍添加獨立的部分 – 因為所有東西都糾纏在一起。

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

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

5. 查看日志信息，而不是運行結(jié)果。還好這并不普遍，但是我卻見過一個非常有能力的開發(fā)人員這么干過。要知道，真正重要的是方法的運行結(jié)果，而不是日志中都打印了什么，因為即使代碼中有錯誤，測試也可能會通過。

從總結(jié)的五大弊端來看，有思想上的滯后，有技術(shù)上的缺陷，有人為能力的限制等，當(dāng)然還有很多，這五條是最常見或最難處理的。只能根據(jù)開發(fā)團(tuán)隊自己內(nèi)部調(diào)整，但也可以使用一定的測試工具（PRQA與Parasoft測試工具性價比非常高）。

標(biāo)簽：軟件測試技術(shù)

本站文章除注明轉(zhuǎn)載外，均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載，但請務(wù)必注明出處、不得修改原文相關(guān)鏈接，如果存在內(nèi)容上的異議請郵件反饋至chenjj@fc6vip.cn

上一篇：提高代碼質(zhì)量之如何設(shè)計函數(shù) 下一篇：C/C++單元測試框架昂貴的原因