程序員為什么不寫單元測試-

第第頁程序員為什么不寫單元測試?程序員為什么不寫單元測試?

發(fā)表于：2023-12-21來源：：點(diǎn)擊數(shù)：標(biāo)簽：

[分析]程序員為什么不寫單元測試?(3)單元測試工具三、程序員緣何拒絕編寫單元測試?我們已經(jīng)知道了單元測試是多么重要的。為什么程序員仍然不編寫單元測試呢?為什么程序員總是有理由拒絕編寫單元測試呢?1、編寫單元測試，增加了工作負(fù)擔(dān)，會(huì)延緩項(xiàng)目進(jìn)

[分析]程序員為什么不寫單元測試?(3)單元測試工具

三、程序員緣何拒絕編寫單元測試?

我們已經(jīng)知道了單元測試是多么重要的。為什么程序員仍然不編寫單元測試呢?為什么程序員總是有理由拒絕編寫單元測試呢?

1、編寫單元測試，增加了工作負(fù)擔(dān)，會(huì)延緩項(xiàng)目進(jìn)度?

這是筆者在多次討論和調(diào)查中見到程序員拒絕編寫單元測試的最多理由?！盀榱送瓿删幋a任務(wù)，沒有足夠的時(shí)間編寫單元測試。編寫單元測試會(huì)導(dǎo)致不能按時(shí)完成編碼任務(wù),推遲項(xiàng)目進(jìn)度”。事實(shí)上真的是這樣的嗎?

軟件有著其特殊的生命周期，軟件開發(fā)也具有特殊性。

首先，我們需要提供給用戶的至少是一個(gè)能運(yùn)行的產(chǎn)品。絕對不能是一堆不能運(yùn)行的和充滿了“異味”的死代碼。只有能夠運(yùn)行的，滿足客戶需求的代碼才是真正有用的代碼。這時(shí)，代碼就變成產(chǎn)品了。

很多程序員只注重編寫代碼的完成時(shí)間，而乎略了調(diào)試代碼，集成及修改和維護(hù)時(shí)間。

如果沒有單元測試，開發(fā)活動(dòng)會(huì)是這樣情景。

以一個(gè)Web應(yīng)用開發(fā)為例，流程大概如此：業(yè)務(wù)代碼編寫完成打包發(fā)布到服務(wù)器進(jìn)行功能測試發(fā)現(xiàn)問題修改代碼再打包……如此循環(huán)。

任何一個(gè)Web程序員對于這種開發(fā)情景都不會(huì)感到陌生。往往不斷的打包、發(fā)布、功能測試的時(shí)間是代碼編寫的10倍以上。通過集成系統(tǒng)來發(fā)現(xiàn)程序的bug，我們往往很難一下子準(zhǔn)確的定位bug產(chǎn)生的地方。應(yīng)用服務(wù)器提供的錯(cuò)誤信息對于我們來說是非常有限的。

如果為每一個(gè)類都編寫單元測試并讓每一個(gè)方法測試通過，又會(huì)是怎么樣的開發(fā)情景呢?

編寫測試代碼編寫業(yè)務(wù)代碼運(yùn)行測試方法修改代碼讓測試通過所有的類都通過測試打包發(fā)布到服務(wù)器進(jìn)行功能測試發(fā)現(xiàn)bug修改測試代碼修改業(yè)務(wù)代碼測試通過再打包……如此循環(huán)。

從上面的過程顯而易見，我們需要花費(fèi)更多的編碼時(shí)間。因?yàn)樾枰獮槊恳粋€(gè)業(yè)務(wù)類編寫測試代碼。但是，它并不會(huì)導(dǎo)致我們總體需要花費(fèi)更多的時(shí)間。我們只是可以非常輕松的在IDE環(huán)境中運(yùn)行測試方法。

在代碼尚未打包發(fā)布之前我們就已經(jīng)確保了業(yè)務(wù)代碼的正確性。當(dāng)我們把所有通過測試的代碼集成到應(yīng)用服務(wù)器后，出現(xiàn)錯(cuò)誤的機(jī)率要少得多。當(dāng)集成測試后發(fā)現(xiàn)bug時(shí),我們也總是先修改測試類。保證在集成之前所有的類都經(jīng)過測試通過。這樣，功能測試的時(shí)間就成數(shù)量級(jí)的減少,所以總的花費(fèi)時(shí)間要比沒有單元測試要少得多。

另外，如果沒有單元測試，會(huì)經(jīng)常出現(xiàn)一些低級(jí)的錯(cuò)誤，如拼寫錯(cuò)誤、空指針異常等。就因?yàn)橐粋€(gè)小小的拼寫錯(cuò)誤而需要重新打包、發(fā)布一次。如果有單元測試，就可以避免這些低級(jí)的錯(cuò)誤。

如果沒有單元測試，把代碼集成到應(yīng)用服務(wù)器后再發(fā)現(xiàn)錯(cuò)誤時(shí)，我們往往更多的是憑借自己的經(jīng)驗(yàn)來判斷問題出在哪里。對于沒有經(jīng)驗(yàn)的程序