摘要：而測(cè)試驅(qū)動(dòng)開(kāi)發(fā)技術(shù)并不只是單純的測(cè)試工作。需求向來(lái)就是軟件開(kāi)發(fā)過(guò)程中感覺(jué)最不好明確描述易變的東西。這里說(shuō)的需求不只是指用戶(hù)的需求，還包括對(duì)代碼

可能很多人和我一樣, 首次聽(tīng)到"前端架構(gòu)"這個(gè)詞, 第一反應(yīng)是: "前端還有架構(gòu)這一說(shuō)呢?" 在后端開(kāi)發(fā)領(lǐng)域, 系統(tǒng)規(guī)劃和可擴(kuò)展性非常關(guān)鍵, 因此架構(gòu)師備受重視, 早在開(kāi)發(fā)工作啟動(dòng)之前, 他們就被邀請(qǐng)加入到項(xiàng)目中, 而且他們會(huì)跟客戶(hù)討論即將建成的平臺(tái)的架構(gòu)要求, 使用還什么技術(shù)棧? 內(nèi)容類(lèi)型是什么? 這些內(nèi)容如何被創(chuàng)建?軟件架構(gòu)師的職責(zé)就是要保證項(xiàng)目中每一步都在總體架構(gòu)的指導(dǎo)下進(jìn)行, 而不會(huì)隨機(jī)決定.

現(xiàn)在的前端領(lǐng)域, 隨著JS框架, UI框架和各種庫(kù)的豐富, 前端架構(gòu)也變得十分的重要. 如果一個(gè)大型項(xiàng)目沒(méi)有合理的前端架構(gòu)設(shè)計(jì), 那么前端代碼可能因?yàn)椴煌拈_(kāi)發(fā)人員隨意的引入各種庫(kù)和UI框架, 導(dǎo)致代碼量變得異常臃腫, 最終結(jié)果可能是代碼變得無(wú)法維護(hù), 頁(yè)面性能低下,不得已只能推翻重構(gòu). 所以我們需要在項(xiàng)目開(kāi)始前, 同樣的需要對(duì)前端代碼進(jìn)行架構(gòu), 一旦前端架構(gòu)師設(shè)計(jì)出所有前端開(kāi)發(fā)人員都要遵循的檢驗(yàn)機(jī)制, 建立起系統(tǒng)設(shè)計(jì)的規(guī)范, 那么項(xiàng)目就擁有了可以衡量代碼質(zhì)量的標(biāo)準(zhǔn), 前端開(kāi)發(fā)人員也能享受到更高效的工作流. 所以, 前端架構(gòu)的定義可以用以下一句話(huà)來(lái)總結(jié):

前端架構(gòu)是一系列工具和流程的集合, 旨在提升前端代碼的質(zhì)量, 并實(shí)現(xiàn)高效, 可持續(xù)的工作流.

本系列的前端架構(gòu)文章, 將分別圍繞前端架構(gòu)的四個(gè)核心展開(kāi), 分別是代碼, 流程, 測(cè)試, 文檔.

歸根到底, 所有的網(wǎng)站都是由一堆文本文件和資源文件組成的. 當(dāng)我們面對(duì)制作網(wǎng)站所產(chǎn)生的大量代碼時(shí), 就會(huì)發(fā)現(xiàn)為代碼和資源設(shè)定一個(gè)期望是多么重要. 在代碼部分, 我們會(huì)專(zhuān)注于如果實(shí)現(xiàn)系統(tǒng)架構(gòu)中的HTML, CSS, JavaScript.

現(xiàn)在早已過(guò)了FTP上傳文件的時(shí)代, 那么現(xiàn)在重要的是思考怎么用工具和流程構(gòu)建一個(gè)高效且避免出錯(cuò)的工作流. 工作流變得越來(lái)越復(fù)雜, 那些用于它們的工具也同樣如此. 這些工具在提高生產(chǎn)力, 加快效率和保持代碼一致性上帶來(lái)了驚人的效果, 但也伴隨著過(guò)度工程化和抽象化的風(fēng)險(xiǎn). 所以, 現(xiàn)有的工作流是需要改變的.

要構(gòu)建一個(gè)可擴(kuò)展和可持續(xù)優(yōu)化的系統(tǒng), 必須保證新代碼和老代碼能夠很好的兼容. 我們的代碼不會(huì)獨(dú)立存在, 它們都是大型系統(tǒng)中的一部分. 創(chuàng)建覆蓋面廣泛的測(cè)試方案, 能確保老代碼還能正常運(yùn)作.

一般而言, 如果不是團(tuán)隊(duì)中的重要成員要離開(kāi), 我們幾乎都不會(huì)意識(shí)到文檔的重要性. 等到那個(gè)時(shí)候, 大家將不得不停下手頭的工作, 優(yōu)先編寫(xiě)所有的文檔. 作為前端機(jī)構(gòu)師, 你要善于在項(xiàng)目開(kāi)發(fā)的同時(shí)編寫(xiě)良好的文檔.

軟件測(cè)試是在規(guī)定的條件下對(duì)程序進(jìn)行操作, 以發(fā)現(xiàn)程序中的錯(cuò)誤, 衡量軟件質(zhì)量, 并對(duì)其是否能滿(mǎn)足設(shè)計(jì)要求進(jìn)行評(píng)估的過(guò)程, 軟件測(cè)試的目的是希望以最小的代價(jià)盡可能多地找出軟件中潛在的錯(cuò)誤和缺陷.

首先,測(cè)試人員會(huì)針對(duì)開(kāi)發(fā)人員開(kāi)發(fā)的功能寫(xiě)出測(cè)試用例, 例如表單應(yīng)該填入的數(shù)據(jù), 頁(yè)面單擊順序, 以及最后頁(yè)面期待的效果, 然后, 測(cè)試人員會(huì)按照用例一步步進(jìn)行手工校驗(yàn), 如果頁(yè)面行為異常, 例如無(wú)法打開(kāi)頁(yè)面或生成的數(shù)據(jù)不準(zhǔn)確, 則會(huì)在企業(yè)缺陷管理系統(tǒng)中提交缺陷記錄, 供開(kāi)發(fā)人員進(jìn)行修正. 在開(kāi)發(fā)過(guò)程中, 如果有新版本編譯出來(lái), 測(cè)試人員需要根據(jù)測(cè)試用例重新測(cè)試, 確認(rèn)是否有新缺陷, 或者老缺陷是否已經(jīng)得到了修正.

長(zhǎng)久以來(lái), 這種傳統(tǒng)手工測(cè)試在各大公司廣泛應(yīng)用, 并已被證明能夠行知有效的保證產(chǎn)品質(zhì)量, 但伴隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展, 這種傳統(tǒng)的測(cè)試模式已經(jīng)顯示出越來(lái)越多的瓶頸.

1. 重復(fù)性工作, 測(cè)試質(zhì)量低

現(xiàn)在的互聯(lián)網(wǎng)產(chǎn)品開(kāi)發(fā)研究的是短平快, 小步快走, 短則兩三天, 長(zhǎng)則一星期就會(huì)發(fā)布新版本. 在這短短的時(shí)間里, 測(cè)試人員需要把新版本部署到測(cè)試環(huán)境, 更新數(shù)據(jù)庫(kù) 然后對(duì)所有的測(cè)試用例進(jìn)行手工校驗(yàn). 這個(gè)過(guò)程事件緊迫, 工作量大, 而且具有很高的機(jī)械性和重復(fù)性, 當(dāng)測(cè)試人員長(zhǎng)期工作在重復(fù)性的驗(yàn)證事物上, 往往會(huì)因?yàn)樗季S習(xí)慣而忽略新出現(xiàn)的問(wèn)題, 最后導(dǎo)致不僅測(cè)試人員自身缺乏工作熱情, 而且測(cè)試質(zhì)量更難以保證.

2. 測(cè)試效率低

手工測(cè)試天生就決定了它的執(zhí)行效率很低, 測(cè)試人員需要根據(jù)測(cè)試用例逐行逐字閱讀, 然后在頁(yè)面上一步步填寫(xiě)表單, 在單擊按鈕提交, 這是一個(gè)非常繁瑣的過(guò)程. 而遇到復(fù)雜的業(yè)務(wù)流程更是涉及方方面面, 作者甚至見(jiàn)過(guò)一個(gè)多小時(shí)都無(wú)法完成的測(cè)試案例. 到了開(kāi)發(fā)后期, 可能每天或每?jī)商炀鸵l(fā)布一個(gè)版本進(jìn)行測(cè)試, 如果一個(gè)軟件系統(tǒng)的功能點(diǎn)有幾千甚至上萬(wàn)個(gè), 手工測(cè)試將特別耗時(shí)和繁瑣, 不僅消耗了大量的人力, 還可能影響到產(chǎn)品的如期發(fā)布.

3. 無(wú)法保證覆蓋代碼全路徑

是否有良好的測(cè)試覆蓋是考核測(cè)試成熟度的重要指標(biāo), 其核心思想是對(duì)相同的業(yè)務(wù)邏輯提供多組甚至幾十組輸入, 全面覆蓋到業(yè)務(wù)中的大多數(shù)路徑, 重點(diǎn)考察軟件的邊界行為. 比如某個(gè)頁(yè)面輸入框的字符個(gè)數(shù)在開(kāi)發(fā)中被限制為256個(gè)字符, 但測(cè)試人員很可能漏掉這樣的極端輸入情況. 由于手工測(cè)試效率很低, 不要說(shuō)進(jìn)行幾十組數(shù)據(jù)的測(cè)試, 就是幾組可能都難以實(shí)施. 另外, 有些軟件缺陷需要在大量數(shù)據(jù)或者大量并發(fā)用戶(hù)的情況下才會(huì)暴露, 很難通過(guò)手工測(cè)試保證代碼的全路徑覆蓋.

4. 無(wú)法有效兼顧多瀏覽器, 多平臺(tái)

Web前端的測(cè)試環(huán)境復(fù)雜, 兼容性要求高, 特別是要同時(shí)兼顧多種操作系統(tǒng), 包括Window, Mac OS和Linux, 以及不同的瀏覽器IE, Edege, Chrome, Safari等, 還要考慮移動(dòng)端的IOS, Andorid等操作系統(tǒng), 其排列組合之后將會(huì)是通過(guò)手工測(cè)試無(wú)法企及的數(shù)字. 很難想象有那個(gè)公司能夠投入巨大的人力成本完成如此龐大的手工測(cè)試.

1. 單元測(cè)試(Unit Test)

在軟件開(kāi)發(fā)過(guò)程中, 最基本的測(cè)試就是單元測(cè)試, 這是針對(duì)程序單元(軟件設(shè)計(jì)的最小單位)來(lái)正確性檢驗(yàn)的測(cè)試工作. 程序單元是應(yīng)用的最小可測(cè)試部件. 在過(guò)程化編程中, 一個(gè)單元就是單個(gè)程序, 函數(shù), 過(guò)程等; 對(duì)于面向?qū)ο缶幊? 最小單元就是方法. 在企業(yè)的質(zhì)量控制體系中, 單元測(cè)試是由開(kāi)發(fā)部門(mén)在軟件提交測(cè)試部門(mén)前完成.

單元測(cè)試的目標(biāo)是打破程序單元間的依賴(lài)關(guān)系, 隔離單元并證明這些單個(gè)單元是正確的, 所以單元測(cè)試應(yīng)該無(wú)依賴(lài)和隔離, 通常在單元測(cè)試中, 把系統(tǒng)的依賴(lài)組件提取出來(lái), 用測(cè)試替身(Test Double)取而代之, 把單元測(cè)試把注意力集中放在測(cè)試"單元"的邏輯上面而不是和第三方系統(tǒng)的交互上.

2. 集成測(cè)試(Integration Test)

即使一個(gè)程序在單元測(cè)試中運(yùn)作良好, 也不能確定他們放在一起能正常工作, 集成測(cè)試是取出應(yīng)用程序里可以獨(dú)立運(yùn)行的組件, 通常是一些單元的集合, 來(lái)測(cè)試這部分單元作為一個(gè)整體的表現(xiàn), 以驗(yàn)證他們能否協(xié)調(diào)一致的運(yùn)作. 集成測(cè)試一般位于單元測(cè)試之后 端到端測(cè)試之前.

例如一個(gè)常見(jiàn)的集成測(cè)試場(chǎng)景是使用數(shù)據(jù)組件對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作的測(cè)試. 測(cè)試人員需要安裝并配置好數(shù)據(jù)庫(kù), 然后在數(shù)據(jù)庫(kù)里插入預(yù)先準(zhǔn)備好的數(shù)據(jù), 再執(zhí)行需要測(cè)試的組件, 運(yùn)行完畢后檢驗(yàn)數(shù)據(jù)庫(kù)里的數(shù)據(jù). 在這個(gè)測(cè)試場(chǎng)景中, 被測(cè)單元依賴(lài)數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)模塊, 所以它不是一個(gè)單元測(cè)試. 但是它也沒(méi)有模擬一個(gè)完整的用戶(hù)真實(shí)場(chǎng)景, 所以它也不是一個(gè)端到端的測(cè)試.

3. 端到端測(cè)試(End-to-End Test)

端到端測(cè)試(通?？s寫(xiě)為E2E)是把產(chǎn)品或服務(wù)當(dāng)做一個(gè)整體進(jìn)行驗(yàn)證, 典型的做法是模擬真實(shí)的用戶(hù)場(chǎng)景, 通過(guò)與系統(tǒng)的需求定義做比較, 來(lái)發(fā)現(xiàn)產(chǎn)品和需求定義不符合或存在矛盾的地方, 其最終目的是為了發(fā)布產(chǎn)品. 例如在Web應(yīng)用程序中, 測(cè)試人員會(huì)啟動(dòng)服務(wù)器, 打開(kāi)瀏覽器, 訪(fǎng)問(wèn)被測(cè)網(wǎng)頁(yè), 并操作網(wǎng)頁(yè)上需要測(cè)試的功能, 檢查瀏覽器中發(fā)生的特定的事件, 以確保被測(cè)功能可以正常運(yùn)行.

端到端測(cè)試通常由測(cè)試部門(mén)完成, 一般有以下特性:

需要搭建專(zhuān)門(mén)的測(cè)試環(huán)境模擬真實(shí)的用戶(hù)場(chǎng)景, 成本較高

測(cè)試用例復(fù)雜, 運(yùn)行時(shí)間長(zhǎng)

一旦測(cè)試發(fā)現(xiàn)問(wèn)題, 由于涉及的模塊比較多, 定位問(wèn)題難度較高

端到端測(cè)試可以手工完成, 也可以變現(xiàn)測(cè)試框架和測(cè)試代碼自動(dòng)執(zhí)行. 在Web前端應(yīng)用中, 端到端測(cè)試通常從用戶(hù)界面開(kāi)始, 核實(shí)用戶(hù)與應(yīng)用之間的交互, 確保用戶(hù)界面向用戶(hù)提供了適當(dāng)?shù)脑L(fǎng)問(wèn)測(cè)試對(duì)象功能的操作, 同時(shí)還要確保內(nèi)部的對(duì)象符合預(yù)期要求. 如果進(jìn)行手工測(cè)試的話(huà), 效率低下, 無(wú)法滿(mǎn)足快速迭代的Web前端應(yīng)用的測(cè)試需求, 所以迫切需要將Web前端應(yīng)用的端到端測(cè)試自動(dòng)化.

1. TDD的優(yōu)勢(shì)

TDD的基本思路就是通過(guò)測(cè)試來(lái)推動(dòng)整個(gè)開(kāi)發(fā)的進(jìn)行。而測(cè)試驅(qū)動(dòng)開(kāi)發(fā)技術(shù)并不只是單純的測(cè)試工作。

需求向來(lái)就是軟件開(kāi)發(fā)過(guò)程中感覺(jué)最不好明確描述、易變的東西。這里說(shuō)的需求不只是指用戶(hù)的需求，還包括對(duì)代碼的使用需求。很多開(kāi)發(fā)人員最害怕的就是后期還要修改某個(gè)類(lèi)或者函數(shù)的接口進(jìn)行修改或者擴(kuò)展，為什么會(huì)發(fā)生這樣的事情就是因?yàn)檫@部分代碼的使用需求沒(méi)有很好的描述。測(cè)試驅(qū)動(dòng)開(kāi)發(fā)就是通過(guò)編寫(xiě)測(cè)試用例，先考慮代碼的使用需求（包括功能、過(guò)程、接口等），而且這個(gè)描述是無(wú)二義的，可執(zhí)行驗(yàn)證的。

通過(guò)編寫(xiě)這部分代碼的測(cè)試用例，對(duì)其功能的分解、使用過(guò)程、接口都進(jìn)行了設(shè)計(jì)。而且這種從使用角度對(duì)代碼的設(shè)計(jì)通常更符合后期開(kāi)發(fā)的需求。可測(cè)試的要求，對(duì)代碼的內(nèi)聚性的提高和復(fù)用都非常有益。因此測(cè)試驅(qū)動(dòng)開(kāi)發(fā)也是一種代碼設(shè)計(jì)的過(guò)程。

開(kāi)發(fā)人員通常對(duì)編寫(xiě)文檔非常厭煩，但要使用、理解別人的代碼時(shí)通常又希望能有文檔進(jìn)行指導(dǎo)。而測(cè)試驅(qū)動(dòng)開(kāi)發(fā)過(guò)程中產(chǎn)生的測(cè)試用例代碼就是對(duì)代碼的最好的解釋。

快樂(lè)工作的基礎(chǔ)就是對(duì)自己有信心，對(duì)自己的工作成果有信心。當(dāng)前很多開(kāi)發(fā)人員卻經(jīng)常在擔(dān)心：“代碼是否正確？”“辛苦編寫(xiě)的代碼還有沒(méi)有嚴(yán)重bug？”“修改的新代碼對(duì)其他部分有沒(méi)有影響？”。這種擔(dān)心甚至導(dǎo)致某些代碼應(yīng)該修改卻不敢修改的地步。測(cè)試驅(qū)動(dòng)開(kāi)發(fā)提供的測(cè)試集就可以作為你信心的來(lái)源。

當(dāng)然測(cè)試驅(qū)動(dòng)開(kāi)發(fā)最重要的功能還在于保障代碼的正確性，能夠迅速發(fā)現(xiàn)、定位bug。而迅速發(fā)現(xiàn)、定位bug是很多開(kāi)發(fā)人員的夢(mèng)想。針對(duì)關(guān)鍵代碼的測(cè)試集，以及不斷完善的測(cè)試用例，為迅速發(fā)現(xiàn)、定位bug提供了條件。

測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的基本思想就是在開(kāi)發(fā)功能代碼之前，先編寫(xiě)測(cè)試代碼。也就是說(shuō)在明確要開(kāi)發(fā)某個(gè)功能后，首先思考如何對(duì)這個(gè)功能進(jìn)行測(cè)試，并完成測(cè)試代碼的編寫(xiě)，然后編寫(xiě)相關(guān)的代碼滿(mǎn)足這些測(cè)試用例。然后循環(huán)進(jìn)行添加其他功能，直到完全部功能的開(kāi)發(fā)。

測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的基本過(guò)程如下：

明確當(dāng)前要完成的功能?？梢杂涗洺梢粋€(gè) TODO 列表。

快速完成針對(duì)此功能的測(cè)試用例編寫(xiě)。

測(cè)試代碼編譯不通過(guò)。

編寫(xiě)對(duì)應(yīng)的功能代碼。

測(cè)試通過(guò)。

對(duì)代碼進(jìn)行重構(gòu)，并保證測(cè)試通過(guò)。

循環(huán)完成所有功能的開(kāi)發(fā)。

Jasmine應(yīng)該算是最成熟的Javascript測(cè)試框架，它自帶斷言和測(cè)試執(zhí)行環(huán)境, 并有擁有靈巧而明確的語(yǔ)法可以讓你輕松的編寫(xiě)測(cè)試代碼。

Mocha同樣也是一個(gè)前端框架, 它上手簡(jiǎn)單且有豐富的插件.如果想學(xué)習(xí)的, 可以看一下阮一峰的教程:測(cè)試框架 Mocha 實(shí)例教程

Karma是由Google團(tuán)隊(duì)開(kāi)發(fā)的一個(gè)測(cè)試工具, 它不是一個(gè)測(cè)試框架, 只是一個(gè)跑測(cè)試的驅(qū)動(dòng). 你可以通過(guò)karma的配置文件集合你喜歡的框架, 斷言庫(kù)和瀏覽器.

Web前端測(cè)試與集成——Jasmine/Selenium/Protractor/Jenk

IBM: 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)(TDD)