BlueDavy之技術(shù)Blog

既然測(cè)試是好的，那就把它發(fā)揮到極限。
測(cè)試是好的，這一點(diǎn)無(wú)可厚非，幾乎做軟件的人都是認(rèn)可的，本篇只是談?wù)劀y(cè)試中的單元測(cè)試部分，單元測(cè)試的目的是為了保證類(lèi)中的方法是符合設(shè)計(jì)時(shí)的需求的，需求驅(qū)動(dòng)似的類(lèi)實(shí)現(xiàn)，^_^

單元測(cè)試的好處
1、保證類(lèi)對(duì)于設(shè)計(jì)以及需求的符合
      在沒(méi)有單元測(cè)試的情況下，其實(shí)是很難保證類(lèi)對(duì)于設(shè)計(jì)以及需求的符合的，很多情況往往會(huì)因?yàn)殚_(kāi)發(fā)人員本身的因素將實(shí)現(xiàn)代碼復(fù)雜化，并且編寫(xiě)出很多設(shè)計(jì)和需求根本不需要的東西。
2、降低調(diào)試的復(fù)雜性
      想想在沒(méi)有單元測(cè)試的情況下，調(diào)試通常是集成時(shí)才做的，這個(gè)時(shí)候要通過(guò)慢慢的跟蹤來(lái)查找問(wèn)題的原因，而在web系統(tǒng)中就更痛苦了，總是要重啟，如果不想那么痛苦，就采用單元測(cè)試吧。
3、減少集成時(shí)出錯(cuò)的機(jī)率
      單元測(cè)試可保證暴露給外部的API的正確性，減少要通過(guò)集成才發(fā)現(xiàn)錯(cuò)誤的現(xiàn)象。
4、保證重構(gòu)和簡(jiǎn)單設(shè)計(jì)的可行
      想想，如果沒(méi)有單元測(cè)試，怎么敢對(duì)代碼做重構(gòu)呢，如果沒(méi)有單元測(cè)試，簡(jiǎn)單設(shè)計(jì)很難通過(guò)重構(gòu)去演變成為將來(lái)更好的設(shè)計(jì)。

單元測(cè)試的實(shí)現(xiàn)
單元測(cè)試的實(shí)現(xiàn)采取的方法通常是xUnit，在Java界就是junit了，最重要的仍然不是工具，而是怎么去實(shí)現(xiàn)單元測(cè)試的方法，測(cè)試驅(qū)動(dòng)開(kāi)發(fā)無(wú)疑是最佳的編寫(xiě)測(cè)試的方法，首先根據(jù)設(shè)計(jì)或需求編寫(xiě)測(cè)試，根據(jù)測(cè)試編寫(xiě)代碼，直到測(cè)試通過(guò)為止。
在代碼出現(xiàn)bug時(shí)，一定要先把出現(xiàn)bug的情況補(bǔ)充到測(cè)試中去，接下來(lái)仍然是修改實(shí)現(xiàn)代碼，直到測(cè)試通過(guò)。
單元測(cè)試編寫(xiě)的原則其實(shí)很簡(jiǎn)單，就是測(cè)試一定情況下類(lèi)的執(zhí)行是否符合預(yù)期。
還是舉例來(lái)說(shuō)：
假設(shè)需要編寫(xiě)一個(gè)根據(jù)用戶名和密碼驗(yàn)證用戶的服務(wù)，按照TDD我們首先編寫(xiě)單元測(cè)試類(lèi)，我們應(yīng)該怎么來(lái)編寫(xiě)這個(gè)單元測(cè)試類(lèi)呢，一般可按照一個(gè)這樣的步驟：
1、分析類(lèi)的輸入。
      這點(diǎn)通常是分析類(lèi)依賴(lài)外部什么類(lèi)，需要在測(cè)試類(lèi)中提前注入。
      以上面的服務(wù)來(lái)說(shuō)，通常需要依賴(lài)的是用戶的Dao類(lèi)。
2、分析方法的輸入造成的輸出的影響。
      這點(diǎn)通常是分析方法輸入的參數(shù)對(duì)執(zhí)行結(jié)果造成的影響。
      以上面的服務(wù)來(lái)說(shuō)，輸入的參數(shù)為用戶名和密碼，這個(gè)時(shí)候會(huì)有幾種情況會(huì)出現(xiàn)：
      2.1 用戶名或密碼為null
            在這種情況下，假設(shè)期待的輸出為false
      2.2 用戶名和密碼都為null
            在這種情況下，假設(shè)期待的輸出為false
      2.3 輸入的用戶名和密碼在系統(tǒng)中存在
            在這種情況下，假設(shè)期待的輸出為true
      2.4 用戶名或密碼其中一項(xiàng)輸入不正確，驗(yàn)證不通過(guò)
            在這種情況下，假設(shè)期待的拋出AuthronizedException
在經(jīng)過(guò)這樣的分析后，就可以開(kāi)始編寫(xiě)測(cè)試類(lèi)了，編寫(xiě)的測(cè)試類(lèi)如下(示例代碼而已)：

在編寫(xiě)完測(cè)試類(lèi)后就可以開(kāi)始編寫(xiě)實(shí)現(xiàn)代碼了，實(shí)現(xiàn)代碼在編寫(xiě)的時(shí)候很簡(jiǎn)單，只要能夠保證測(cè)試通過(guò)就完事，在測(cè)試通過(guò)后可以開(kāi)始考慮重構(gòu)的事，重構(gòu)仍然只要保證測(cè)試通過(guò)即可，其實(shí)這個(gè)時(shí)候就可以看到，簡(jiǎn)單設(shè)計(jì)就變得可行了，因?yàn)榭梢酝ㄟ^(guò)重構(gòu)來(lái)提升設(shè)計(jì)。
如果將來(lái)這段代碼出現(xiàn)bug，就把bug中的輸入情況也編寫(xiě)為一個(gè)測(cè)試方法進(jìn)行測(cè)試，開(kāi)始運(yùn)行就應(yīng)該和bug一樣出現(xiàn)問(wèn)題，這時(shí)只需去修正實(shí)現(xiàn)代碼，直到測(cè)試通過(guò)為止，那么bug也就自然被修正了。
簡(jiǎn)單的單元測(cè)試的編寫(xiě)較為簡(jiǎn)單，復(fù)雜的單元測(cè)試則可能需要使用Mock來(lái)模擬一些環(huán)境，Mock方面的工具有很多，大家可以去參考相關(guān)的開(kāi)源工具的網(wǎng)站。    

經(jīng)驗(yàn)總結(jié)
對(duì)于單元測(cè)試通常很多人都有疑問(wèn)，執(zhí)行起來(lái)的時(shí)候經(jīng)常是不夠徹底，特別是在項(xiàng)目時(shí)間緊張的情況下，總是覺(jué)得編寫(xiě)測(cè)試是一種耽誤時(shí)間的事，其實(shí)編寫(xiě)單元測(cè)試會(huì)為你節(jié)省非常多的時(shí)間，想想我們大部分的項(xiàng)目都是在集成、修改bug和維護(hù)上消耗了大量的時(shí)間，既然單元測(cè)試這么好，那么我們就實(shí)現(xiàn)單元測(cè)試吧。
在單元測(cè)試中最重要的注意點(diǎn)就是不要依賴(lài)于正常的運(yùn)行數(shù)據(jù)，所有的數(shù)據(jù)都要通過(guò)代碼模擬出來(lái)，在測(cè)試完畢后清除，避免造成測(cè)試對(duì)于運(yùn)行數(shù)據(jù)的依賴(lài)，同時(shí)也避免測(cè)試數(shù)據(jù)對(duì)于實(shí)際運(yùn)行系統(tǒng)的影響。