走進(jìn)單元測試：單元測試背后的思考和感悟

1、走進(jìn)單元測試：單元測試背后的思考和感悟就要完成所有的單元測試的任務(wù)了，做了將近三個(gè)月的時(shí)間，如果放在以前我有一肚子苦水要述說，不過經(jīng)歷了一些思想上的洗禮之后，不在那么單純，只為把手頭工作做的更加出色 而已！這是單元測試最后一篇了，來做個(gè)總結(jié)把！目錄：好的單元測試應(yīng)該具有的特點(diǎn)單元測試的命名規(guī)范建立自己的公共調(diào)用庫單元測試帶給我的思考和感悟總結(jié)圖示1、好的單元測試應(yīng)該具備的特點(diǎn)一個(gè)好的單元測試一定有它具備的特點(diǎn)，下面就來說說那些主要的特點(diǎn)！主要概括為-A-TRIP原則：自動化 Automatic徹底性 fThorough可重復(fù)性-Repeatable獨(dú)立性 Indepentdent專業(yè)性 Pro

2、fessional恰到好處的單元測試會使你的工作輕松，代碼整潔干凈，亂用，沒有準(zhǔn)則的用會浪費(fèi)你大量的時(shí)間，不但沒有效果還會是工期延誤，所有了解單元測試很重要！自動化a）不需要人的參與，有的時(shí)候只是輕輕的點(diǎn)擊一個(gè)按鈕就能自動執(zhí)行，所以自動化的標(biāo) 志是不能比點(diǎn)擊一個(gè)按鈕的過程還要復(fù)雜！b）在簽入其它的測試代碼時(shí)不能對現(xiàn)有的代碼造成影響！c）能夠自動識別測試是失敗還是成功（VS2008以后的版本都集成了這個(gè)功能）！d）在任何時(shí)候，任何地方都能自動運(yùn)行（所以“ Moles”技術(shù)就是關(guān)鍵）！核心：執(zhí)行測試代碼和檢查測試結(jié)果都必須自動化（VS2008以后版本都實(shí)現(xiàn)這個(gè)功能了） ！總結(jié)：I,不要引入一個(gè)由于

3、需要手動步驟而打破單元測試的自動化模型的測試！II ,對于測試所需要的任何條件（大部分是數(shù)據(jù)庫） 都應(yīng)該讓它成為自動化測試的一部分，如果有需要可以使用 Mole技術(shù)！徹底性所謂的徹底性就是說你的測試案例必須要考慮的全面，應(yīng)該把可能出現(xiàn)的問題都做成測試案例！具體從哪些方面著手，可以參閱這篇：走進(jìn)單元測試：測試需要從哪些方面著手可重復(fù)性a）每個(gè)測試案例應(yīng)該獨(dú)立于所有的其它測試，而且必須獨(dú)立于周圍的（系統(tǒng)）環(huán)境！b）測試代碼能夠一次又一次的運(yùn)行，在不修改代碼的前提下都能產(chǎn)生一樣的結(jié)果，否則 有BUGc）不要把測試代碼寫死，應(yīng)該寫的更加靈活一點(diǎn)，運(yùn)用封裝，重構(gòu)等等的思想！d）不要讓測試本身也出現(xiàn) BU

4、G確保測試代碼的正確性！獨(dú)立的a）每個(gè)測試應(yīng)該有很強(qiáng)的針對性，也就說一個(gè)測試只能測試一個(gè)方面的內(nèi)容！b）每個(gè)測試應(yīng)該獨(dú)立于環(huán)境（軟件所處的系統(tǒng)環(huán)境）和其它測試！總結(jié)：I,每個(gè)測試都不能夠依賴于其它測試，你可以在任何時(shí)間運(yùn)行這個(gè)測試而不受其 它測試的影響，每一個(gè)測試都應(yīng)該是一座孤島！II ,所以測試一個(gè)函數(shù)都有很多個(gè)測試方法，只有這樣才是真正的測試！專業(yè)的a）所謂的專業(yè)就是你的測試代碼應(yīng)該跟你的開發(fā)代碼保持一樣的風(fēng)格，如：簡潔明了，封裝，解耦，不要出現(xiàn)“ Hard Core ”，要靈活一點(diǎn)！b)拒絕編寫冗余的測試代碼，千萬要小心不要掉進(jìn)這個(gè)陷阱，因?yàn)橄裎覀冞@樣的新手在 初期都不會注意到這樣的問題

5、，所以我們要牢記在心里！c)遵循普遍規(guī)則：1.維護(hù)封裝2.降低耦合！總結(jié)：不管怎么樣你都應(yīng)該認(rèn)認(rèn)真真的對待單元測試，代碼的質(zhì)量要求都應(yīng)該跟開發(fā)代碼同等水平，這是作為開發(fā)者必備的素質(zhì)！2、單元測試的命名規(guī)范在我們項(xiàng)目的中， 可能需要測試的方法有成千上百個(gè)，而每一個(gè)測試方法都有可能寫三個(gè)以上的測試案例，那么怎么來維護(hù)這么測試案例呢？所以我們應(yīng)該規(guī)范方法的命名方式，那么其他人在閱讀你的測試代碼時(shí)，直接通過方法名就能知道你的測試案例是測試哪個(gè)方面的了！Note：單元測試案例類似于一個(gè)可執(zhí)行文檔，可以幫助其它的開發(fā)人員了解方法的作用！在我們的項(xiàng)目中是這樣規(guī)定的：方法名+ _ +你測試是哪個(gè)方面的內(nèi)容+

6、_ + 產(chǎn)生的結(jié)果！下面我就舉個(gè)列子，下面的測試方法命名就是針對這個(gè)函數(shù)來命名的，如：public DataSet GetDetails(int ID)(/方法的作用：這個(gè)一個(gè)獲取數(shù)據(jù)，并包裝成一個(gè)DataS參數(shù)是一個(gè)bondAppID,那么我們怎么來設(shè)計(jì)案例和命名方法名呢？首先設(shè)計(jì)你的測試案例看到這個(gè)方法我就會有這幾個(gè)想法：1,最大值2 ,最小值3 ,剛剛好的值4 ,隨便一個(gè)值5 ,還有的測試案例會隨著你代碼中的邏輯而產(chǎn)生！下面是我的測試案例以及方法名的命名，測試方法是上面的那個(gè)：/ / Input valid bond ,but the cheque is presented Status

7、 /TestMethod()/如果你預(yù)期有數(shù)據(jù)返回，那么就應(yīng)該在最后面加上“RecordFound,這樣別,的時(shí)候就能一目了然了！public void GetDetails_CheckPresentedStatus_RecordFound()(一一/To Do./ /Cancel Status./TestMethod()public void GetDetails_CheckCancelStatus_RecordFound()(一一/To Do./ / Input max./TestMethod()public void GetDetails_CheckDetailsByMaxBoundar

8、yValue_NoRecordFound()(/To Do./ / Input min./TestMethod()public void GetDetails_CheckDetailsByMinBoundaryValue_NoRecordFound()(一一/To DO./ / Any bondID./TestMethod()public void GetDetails_CheckDetailsByAnyBondID_NoRecordFound()(一一/To Do.說一下總的命名規(guī)范a）如果返回值是Bool型的話，應(yīng)該在最后面加上RetrunTrue 或ReturnFalse !如：Chec

9、kRebateHasNewChange_ExistNewChanges_ReturnTrueb）如果返回值是集合或者DataSet之類的類型話，應(yīng)該在最后面加上 RecordFound 或者NoRecordFound !如：GetPurchaseOrder_ByPurchaseOrderId_RecordFoundc）如果是測試異常的話，應(yīng)該在后面加上 ThrowException !如：CreateRebateApplication_ExistSameRebateID_ThrowExceptiond）如果是歲數(shù)據(jù)庫進(jìn)行刪除或者更新，插入的操作時(shí)，應(yīng)該在后面寫上“DataUpdated ”或N

10、oDataUpdated !如：UpdateClientIncome_UpdateIncome_DataUpdated總結(jié)：基本的變動部分都是你中間的描述，中間的描述盡量做到簡潔明了，應(yīng)該以動詞開頭，如：Update , Input ,等等！總結(jié)：好的命名方式可以增強(qiáng)代碼的可讀性，尤其是類似于單元測試這樣的可讀性文檔， 應(yīng)該更加注意這方面的考慮！3、建立自己的公共調(diào)用庫一個(gè)好的單元測試應(yīng)該都有自己的公共調(diào)用庫，這樣能減少很多的冗余代碼，使的代碼簡潔易懂！所以建立了公共庫的單元測試符合了單元測試特點(diǎn)中的專業(yè)性-1.維護(hù)封裝，解耦等等特點(diǎn)！ 建立數(shù)據(jù)庫訪問庫測試中的準(zhǔn)備數(shù)據(jù)從何而來，有的時(shí)候數(shù)據(jù)準(zhǔn)

11、備比較簡單，那么如果傳入的參數(shù)是 DataSet的呢，里面的數(shù)據(jù)比較多呢，或者更新數(shù)據(jù)庫呢，我們應(yīng)該怎么做？那么我們應(yīng)該去數(shù)據(jù)庫中查找數(shù)據(jù)，然后在組合到 DataSet中去，所以建立必要的數(shù)據(jù)庫訪問類很重要！建立自己的公共庫這些是為了你驗(yàn)證數(shù)據(jù)，或者搭建環(huán)境等等的一些用處，提高編寫測試代碼的速度-.受UnitTest.Common+ wi Properties擴(kuò)震Asssrt異常魄證公共集屋數(shù)據(jù)庫訪問Refererices| 刀 Ex匚$ptQrAf&ert； LoggingAssert.es 丁的DbH白后打JyTFntTGty /這是我們建立的公共調(diào)用庫，所以如果建立了庫，對于我們的單元測

12、試將是大有裨益的!4、單元測試帶給我的思考和感悟感悟說實(shí)話從一開始做單元測試的時(shí)候，我對它真的很鄙視， 我覺得它的含金量很少， 編寫單元測試代碼太枯燥了，導(dǎo)致了那時(shí)候我的心態(tài)是多么的浮躁，以至于在思想方面出現(xiàn)了偏差， 感興趣的朋友可以看看這篇文章-工作的思考，是走還是留！經(jīng)過一段時(shí)間的自我反省， 也確實(shí)讓我慢慢的走上了正軌，感興趣的朋友可以看看f迷茫后的感悟！a）做任何一件事都應(yīng)該專心，戒驕戒躁，這是我深有體會的！b）事無大小，不要認(rèn)為你的事很無聊，很枯燥，很不值得一提，但是一旦你做好做精之 后你就發(fā)現(xiàn)原來你不知道的還有這么多啊！c）努力+學(xué)習(xí)方法+工作態(tài)度 -是我這段時(shí)間感悟比較深的一件事！思考前提：我們做的單元測試是在項(xiàng)目后期寫，而且我對我負(fù)責(zé)的模塊是一竅不通的（我是剛剛進(jìn)這個(gè)項(xiàng)目組的），業(yè)務(wù)流程根本不懂！在這樣的前提下，每天先熟悉下流程，看一下代碼，找?guī)ь^大哥幫我講解講解，然后才開始寫單元測試代碼，由此我有了下面三點(diǎn)的思考：a）單元測試不應(yīng)該在后期做，應(yīng)該在項(xiàng)目的開發(fā)時(shí)期去完成它，這個(gè)可能跟我們的項(xiàng)目 本身有原因把！b）對于找一個(gè)還不懂業(yè)務(wù)流程的人來做單元測試自我感覺是有點(diǎn)不合理的，至少會花費(fèi)更多的時(shí)間來熟悉流程。然后再做單元測試！c）項(xiàng)目過程中的代碼編寫習(xí)慣也是很重要的，這是我應(yīng)該要加強(qiáng)和思考的，也是我需要培養(yǎng)的習(xí)慣!5、總結(jié)