Coding:寫(xiě)測(cè)試還是不寫(xiě)測(cè)試?
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時(shí)間:[ 2011/9/21 9:29:46 ] 推薦標(biāo)簽:
在 appWorks有一些問(wèn)題我們常常討論,例如:用什么工具、做什么產(chǎn)品、該怎么營(yíng)銷(xiāo)、該跟誰(shuí)合作、怎么合作、什么時(shí)候增資、該拿多少錢(qián)…等等,這些問(wèn)題往往沒(méi)有一定的答案,也必須要視情況而定。但越是沒(méi)有標(biāo)準(zhǔn)答案的,我認(rèn)為越是應(yīng)該多討論,這樣才能幫助創(chuàng)業(yè)者們根據(jù)自己的情況,定義出適合自己的處理方式。
而關(guān)于編碼,「要不要寫(xiě) 測(cè)試」是其中有一個(gè)這樣的問(wèn)題。我個(gè)人的意見(jiàn)是當(dāng)你要做一個(gè)非常簡(jiǎn)單、用完即丟的MVP,那不必寫(xiě) 測(cè)試。如果邏輯比較復(fù)雜、日后有維護(hù)的必要或是有和人家協(xié)同工作,那你一定要逼迫自己寫(xiě) 測(cè)試。
這不只是完整性、邏輯性或是身為一個(gè)工程師的職責(zé)問(wèn)題,而是你如果不寫(xiě) 測(cè)試,是跟自己過(guò)不去?跟好的 comment/documentation 一樣,不做的話(huà),日后要維護(hù)時(shí),你將會(huì)花更多時(shí)間在弄懂自己當(dāng)初寫(xiě)的 編碼,當(dāng)別人要用你的東西,你也必須花更多時(shí)間跟他解釋?zhuān)@不是跟自己過(guò)不去嗎?
我得承認(rèn)關(guān)于更深入的判斷什么時(shí)候要寫(xiě) 測(cè)試、該怎么寫(xiě),我不是專(zhuān)家。但是讀到一篇文章寫(xiě)得很好,在這里跟大家分享。
1、測(cè)試:讓你用程序功力去挑戰(zhàn)你的程序功力??身為工程師,大家討厭的是不斷的手動(dòng)測(cè)試了,那何不把這些寫(xiě)成程序?況且好的進(jìn)步方法是以己之矛,攻己之盾,這樣不斷的循環(huán)下去,你的程序功力一定突飛猛進(jìn)。
2、測(cè)試:讓你跟你寫(xiě)的程序還有你自己對(duì)話(huà)??當(dāng)你若干時(shí)間之后回來(lái)看自己寫(xiě)的 測(cè)試,你將會(huì)重新檢視自己當(dāng)初的邏輯?這樣復(fù)雜的錯(cuò)誤處理真的有必要嗎?這個(gè)對(duì)象夠獨(dú)立嗎…等等,并且想清楚你寫(xiě)的程序跟整個(gè)系統(tǒng)的架構(gòu)是否吻合。
3、測(cè)試:提醒你程序是用「用了」多少行衡量,而不是「寫(xiě)了」多少行??記住,棒的程序代碼,不是程序代碼!
4、好的測(cè)試:設(shè)計(jì)還包含好的測(cè)試批注??如果你寫(xiě)好的測(cè)試,別人更容易了解你的程序,和如何跟你介接。
5、測(cè)試:讓你可以看穿別人寫(xiě)的編碼??同樣的道理,如果大家都寫(xiě)好的測(cè)試,那你可以更容易了解別人寫(xiě)的 編碼,大家都會(huì)進(jìn)步的更快。
以上,是一些關(guān)于寫(xiě) 測(cè)試 這件事情的觀念,希望能夠讓你更認(rèn)同測(cè)試 編碼 的價(jià)值。或許你有更有趣的經(jīng)驗(yàn)?歡迎留言跟大家分享。
相關(guān)推薦

最新發(fā)布
性能測(cè)試之測(cè)試環(huán)境搭建的方法
2020/7/21 15:39:32軟件測(cè)試是從什么時(shí)候開(kāi)始被企業(yè)所重視的呢?
2020/7/17 9:09:11Android自動(dòng)化測(cè)試框架有哪些?有什么用途?
2020/7/17 9:03:50什么樣的項(xiàng)目適合做自動(dòng)化?自動(dòng)化測(cè)試人員應(yīng)具備怎樣的能力?
2020/7/17 8:57:06幾大市面主流性能測(cè)試工具測(cè)評(píng)
2020/7/17 8:52:11RPA機(jī)器人能夠快速響應(yīng)企業(yè)需求,是怎么做到的?
2020/7/17 8:48:05Bug可以真正消滅嗎?為什么?
2020/7/17 8:43:03軟件測(cè)試基本概念是怎么來(lái)的?軟件測(cè)試生命周期的形成歷經(jīng)了什么?
2020/7/16 9:11:10