沒有單元測(cè)試時(shí)的驗(yàn)證

在學(xué)習(xí)編程和業(yè)務(wù)開發(fā)的工程中，我們有一段時(shí)間總是在討論：?jiǎn)卧獪y(cè)試是否有用？而進(jìn)行這種討論的主要原因是，我們似乎在不使用單元測(cè)試的時(shí)候，項(xiàng)目也可以跑得很好。小到畢業(yè)設(shè)計(jì)時(shí)的內(nèi)容，大到一個(gè)十幾人大小的團(tuán)隊(duì)。我們?cè)O(shè)計(jì)項(xiàng)目、分析需求，然后根據(jù)設(shè)計(jì)的結(jié)果進(jìn)行代碼的編寫，然后進(jìn)行接口或者業(yè)務(wù)執(zhí)行上面的測(cè)試，讓我們知道所編寫的代碼已經(jīng)可以完美的完成計(jì)劃內(nèi)容后，會(huì)請(qǐng)測(cè)試同學(xué)幫我們進(jìn)行代碼測(cè)試，以保證他們確實(shí)完成了計(jì)劃中的內(nèi)容。最終，代碼上線，可喜可賀。

看起來沒什么不好的，直到最終的問題發(fā)生。

我們當(dāng)然會(huì)在開發(fā)的時(shí)候進(jìn)行項(xiàng)目功能的測(cè)試，常用手段諸如用main對(duì)指定的代碼塊驗(yàn)證，或者使用postman對(duì)我們?cè)O(shè)計(jì)的接口進(jìn)行測(cè)試驗(yàn)證。或許中間還存在了一些數(shù)據(jù)庫的修改，比如模擬下單數(shù)據(jù)，或者模擬用戶注冊(cè)。

這些方法是一定程度上可以完成當(dāng)期內(nèi)的功能需求的，否則也不會(huì)有那么多的“單元測(cè)試真的有用嗎”的這種聲音。那么問題是什么呢？

問題是你無法永遠(yuǎn)保證“當(dāng)期的業(yè)務(wù)測(cè)試”就是能覆蓋你本期提供的功能點(diǎn)，以及即便是測(cè)試同學(xué)保存有以往所有測(cè)試用例的自動(dòng)化測(cè)試內(nèi)容，也無法真正的保證你的系統(tǒng)是完好的，因?yàn)闃I(yè)務(wù)功能和軟件功能中間是有隔閡的。

盡管是搞笑圖，但是精準(zhǔn)的命中了我要說的內(nèi)容：

針對(duì)用例設(shè)計(jì)的功能測(cè)試，無法保證你的“系統(tǒng)”正常。

測(cè)試驅(qū)動(dòng)開發(fā)

我們一般在項(xiàng)目開發(fā)中進(jìn)行的功能測(cè)試，是可以保證當(dāng)期中業(yè)務(wù)流程。但是即便功能測(cè)試的過程包含了所有的過往功能，也只能保證業(yè)務(wù)流程是正確的，不能保證你的設(shè)計(jì)在未來的擴(kuò)展中是正確的（舉例就是業(yè)務(wù)可能只需要正常流程，但是沒有異常流程的需求）。

所以，如果要代碼能實(shí)現(xiàn)所有計(jì)劃的功能，就要由開發(fā)者來編寫其對(duì)應(yīng)的測(cè)試模塊。因?yàn)槭情_發(fā)人員，所以知道自己的所有邏輯組合是什么，而根據(jù)這種需求編寫的測(cè)試代碼則可以長(zhǎng)久地對(duì)你的系統(tǒng)進(jìn)行測(cè)試。而這就是就是：

TDD（測(cè)試驅(qū)動(dòng)開發(fā)）

測(cè)試驅(qū)動(dòng)開發(fā)中最主要的準(zhǔn)則是：

在編寫業(yè)務(wù)代碼之前先編寫單元測(cè)試。

這條準(zhǔn)則的目的在于：不要編寫沒有單元測(cè)試的代碼。實(shí)際上我們?cè)诰帉懝δ軜I(yè)務(wù)的時(shí)候，一般都會(huì)假設(shè)一個(gè)入口，然后再經(jīng)過一段邏輯處理之后，最終返回一個(gè)結(jié)果。而先編寫單元測(cè)試的目的，就是先將你的這個(gè)假設(shè)直接落地到代碼中，那么在后續(xù)的編程過程中你就可以忽略這部分的假設(shè)，專注于邏輯編寫，甚至即使你最后忘記了之前的假設(shè)也不要緊，因?yàn)槟阋呀?jīng)將他寫道代碼中了。

而這一準(zhǔn)則的進(jìn)一步拆解，可以將其細(xì)化為三個(gè)準(zhǔn)則：

在編寫不能通過的單元測(cè)試前，不可以編寫生產(chǎn)代碼。

只可編寫剛好不能通過的單元測(cè)試，不能編譯也算。

只可編寫剛好足以通過當(dāng)前失敗測(cè)試的生產(chǎn)代碼。

根據(jù)細(xì)分的這三個(gè)準(zhǔn)則，我們可以將我們編寫一個(gè)邏輯的的步驟變成：寫一個(gè)剛好失敗的單元測(cè)試，然后用剛好滿足邏輯的生產(chǎn)代碼滿足它。這樣一個(gè)小循環(huán)可能只是在一兩分鐘內(nèi)就進(jìn)行一次。而在IDEA等現(xiàn)代IDE的幫助下，可以在test包下的同包路徑創(chuàng)建對(duì)應(yīng)的測(cè)試方法，大大加快了單元測(cè)試的編寫時(shí)間。而通過剛好的異常，讓每一次的業(yè)務(wù)邏輯得到了控制，通過剛好滿足則讓每一次生產(chǎn)代碼的編寫不會(huì)過度發(fā)散。因?yàn)槿绻銓?duì)生產(chǎn)代碼過度設(shè)計(jì)，那么你也需要對(duì)應(yīng)的單元測(cè)試代碼來保證你設(shè)計(jì)的的得當(dāng)性。

如果按這種循環(huán)進(jìn)行編寫，則我們?cè)诰帉憳I(yè)務(wù)代碼的同時(shí)只需要多十幾秒就可以完成單元測(cè)試的編寫。而單元測(cè)試可以完整地覆蓋業(yè)務(wù)單元元。但是隨著業(yè)務(wù)代碼的增加，測(cè)試代碼的數(shù)量也將急劇增加，其對(duì)應(yīng)的管理也是一種挑戰(zhàn)。

系統(tǒng)進(jìn)化的保證

回到最開始的例子，我們說在一些團(tuán)隊(duì)中，我們總是覺得單元測(cè)試是低效的，會(huì)影響業(yè)務(wù)的上線速度。我們也說這種方法看起來沒什么不好的，直到最終的問題發(fā)生。而這最終的問題就是：重構(gòu)。

這里說的重構(gòu)并不一定是大范圍的整體系統(tǒng)重構(gòu)。我們?cè)谥暗奈恼隆度绾巫柚管浖嘶分刑岬剑?strong>要保持軟件設(shè)計(jì)質(zhì)量不退化，必須要在每次需求變更的時(shí)候，根據(jù)變更點(diǎn)調(diào)整原有程序的設(shè)計(jì)結(jié)構(gòu)。

而當(dāng)我們相對(duì)原有的程序結(jié)構(gòu)進(jìn)行調(diào)整的時(shí)候，我們無法確保對(duì)代碼的改動(dòng)能如預(yù)期的工作，也無法保證系統(tǒng)中的某個(gè)修改點(diǎn)是否會(huì)影響到系統(tǒng)的其他部分。舉個(gè)例子：當(dāng)你會(huì)支付的路由進(jìn)行修改的時(shí)候，如果出現(xiàn)意外則會(huì)導(dǎo)致其他支付方式的失敗，但是如果確保功能正常則你需要將所有的支付邏輯都進(jìn)行一遍功能測(cè)試，而仍然可能存在功能點(diǎn)的遺漏（這個(gè)是親身經(jīng)歷）。因?yàn)楹ε滦略黾拥墓δ軙?huì)帶來更多的bug導(dǎo)致加班，最終的結(jié)論就是我們可能會(huì)抗拒對(duì)功能結(jié)構(gòu)的調(diào)整，而變成所謂的“屎上雕花”。所以從這個(gè)角度上來說，如果沒有單元測(cè)試，則軟件將不可避免地直線的退化。

而相反地來說，如果我們的系統(tǒng)包含單元測(cè)試。我們才不用擔(dān)心對(duì)于代碼的修改，每一次調(diào)整都能通過那些“剛好”的單元測(cè)試，那么不論你如何進(jìn)行設(shè)計(jì)模式的重構(gòu)，都不用擔(dān)心引入新的不可預(yù)知的缺陷。

所以當(dāng)有了單元測(cè)試，才能讓我們的系統(tǒng)有了進(jìn)一步的維護(hù)性、擴(kuò)展性，也才有了系統(tǒng)進(jìn)化的可能。

應(yīng)該被重視的單元測(cè)試

我們需要單元測(cè)試來保證系統(tǒng)功能的擴(kuò)展性、可維護(hù)性。但是這并不意味著，只要有單元測(cè)試就可以。事實(shí)上我們應(yīng)當(dāng)如同生產(chǎn)代碼一樣的重視單元測(cè)試。原因很簡(jiǎn)單：

單元測(cè)試代碼同樣會(huì)隨著功能調(diào)整而變得腐化。

而如果當(dāng)它腐化的難以維護(hù)的時(shí)候，誰都不會(huì)愿意去修改它。最終的結(jié)果就是我們不用單元測(cè)試了，然后失去了代碼的擴(kuò)展性。所以測(cè)試代碼必須要隨業(yè)務(wù)代碼的修改而同步修改，并不能因?yàn)閱卧獪y(cè)試只運(yùn)行在測(cè)試環(huán)境而輕視單元測(cè)試的編寫，我們同樣需要讓單元測(cè)試的代碼也足夠整潔，讓其便于維護(hù)。

測(cè)試的邏輯

單元測(cè)試的時(shí)候重要的是體現(xiàn)出當(dāng)前進(jìn)行的測(cè)試內(nèi)容，而讓別人理解測(cè)試內(nèi)容的重中之重是測(cè)試“可讀性”。如果單元測(cè)試的代碼中充滿的一長(zhǎng)串的業(yè)務(wù)邏輯或者斷言內(nèi)容，那么讀起來就會(huì)十分的費(fèi)勁。為了避免開發(fā)人員淹沒在代碼的細(xì)節(jié)中，有一種較為公認(rèn)的單元測(cè)試的構(gòu)造方法：構(gòu)造-操作-檢驗(yàn)（BUILD-OPERATE-CHECK），并使用give-when-then的命名方式來進(jìn)行命名。

舉一個(gè)例子(這里直接用的CLEAN CODE的例子了):

givenPages(xxx); whenRequestIsIssued(xxx); thenResponseShouldBeXML();

其中，第一部分將構(gòu)造測(cè)試數(shù)據(jù)的內(nèi)容分裝到given開頭的方法中；第二部分將操作測(cè)試數(shù)據(jù)的內(nèi)容封裝到when開頭的方法中；第三部分將檢查操作是否得到預(yù)期的結(jié)果封裝到then開頭的方法中。

這樣就屏蔽了絕大部分的代碼細(xì)節(jié)，并用方法的名稱直接描述了測(cè)試的前置條件、處理過程、判斷結(jié)果。同時(shí)當(dāng)我們涉及到一些復(fù)雜流程的判斷的時(shí)候，我們是可以單獨(dú)為單元測(cè)試來編寫一部分額外的方法來支撐單元測(cè)試。這樣可以讓人變這樣可以讓人快速地理解單元測(cè)試的邏輯。

可以放松的部分

盡管說我們需要讓單元測(cè)試保持代碼保持整潔，并需要向生產(chǎn)代碼一樣地重視它。但并不意味著我們的測(cè)試代碼和生產(chǎn)代碼的準(zhǔn)則是完全一樣的。因?yàn)閱卧獪y(cè)試的準(zhǔn)則是具有可讀性的代碼并能精準(zhǔn)地描述關(guān)注的測(cè)試功能邊界。

所以有一些內(nèi)容是不需要和生產(chǎn)代碼保持一致的。其中最明顯的就是性能要求。

我們?cè)诰€上代碼中需要對(duì)系統(tǒng)性能進(jìn)行各種優(yōu)化，但是單元測(cè)試的代碼是跑在測(cè)試環(huán)境中并且單個(gè)邏輯每次只執(zhí)行一遍，對(duì)單元測(cè)試來說，0.1ms的邏輯和1ms的邏輯差距可能并不明顯。這樣的情況下我們可能會(huì)選用一下表達(dá)能力更強(qiáng)的方法來進(jìn)行項(xiàng)目的編寫比如使用"+"號(hào)對(duì)字符串進(jìn)行拼接，我們一般都會(huì)用StringBuilder，但是不得不說直接使用“+”拼接的實(shí)現(xiàn)可讀性更高一點(diǎn)。除此之外還有一些異步的功能可以使用串行化來校驗(yàn)，以便校驗(yàn)每一步的結(jié)果。

單一概念

為了保證每一個(gè)單元測(cè)試中邏輯的可讀性，所以我們希望每一個(gè)單元測(cè)試只對(duì)一個(gè)概念進(jìn)行測(cè)試，這樣就可以用一組give-when-then的方法來對(duì)這個(gè)測(cè)試概念進(jìn)行描述。當(dāng)我們發(fā)現(xiàn)單元測(cè)試存在多個(gè)概念的時(shí)候就會(huì)將他們拆開分別進(jìn)行測(cè)試。這樣就避免了多個(gè)概念聚合在一個(gè)單元測(cè)試方法中的時(shí)候，會(huì)猶豫復(fù)合概念導(dǎo)致掩蓋了一些遺漏的測(cè)試點(diǎn)在其中。同時(shí)也保證了單元測(cè)試的可讀性。

其他原則

除此之外，單元測(cè)試還要保證：

快速性：?jiǎn)卧獪y(cè)試可快速執(zhí)行，支持頻繁測(cè)試。

獨(dú)立性：?jiǎn)卧獪y(cè)試不互相依賴，隨時(shí)以任意順序執(zhí)行。

可重復(fù)性： 單元測(cè)試可以反復(fù)執(zhí)行且結(jié)果統(tǒng)一，否則永遠(yuǎn)會(huì)有功能失敗的借口。

可檢驗(yàn)：?jiǎn)卧獪y(cè)試要明確地通過布爾值來表示檢測(cè)結(jié)果，而非通過其他諸如日志的輔助手段。

及時(shí)性：要在開始編寫業(yè)務(wù)代碼前編寫，讓業(yè)務(wù)代碼去覆蓋測(cè)試。

最后