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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 測試效率低

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

3. 無法保證覆蓋代碼全路徑

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

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

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

1. 單元測試(Unit Test)

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

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

2. 集成測試(Integration Test)

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

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

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

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

端到端測試通常由測試部門完成, 一般有以下特性:

需要搭建專門的測試環(huán)境模擬真實(shí)的用戶場景, 成本較高

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

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

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

1. TDD的優(yōu)勢

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

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

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

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

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

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

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

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

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

快速完成針對此功能的測試用例編寫。

測試代碼編譯不通過。

編寫對應(yīng)的功能代碼。

測試通過。

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

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

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

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

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

Web前端測試與集成——Jasmine/Selenium/Protractor/Jenk

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