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

可能很多人和我一樣, 首次聽到"前端架構"這個詞, 第一反應是: "前端還有架構這一說呢?" 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備受重視, 早在開發工作啟動之前, 他們就被邀請加入到項目中, 而且他們會跟客戶討論即將建成的平臺的架構要求, 使用還什么技術棧? 內容類型是什么? 這些內容如何被創建?軟件架構師的職責就是要保證項目中每一步都在總體架構的指導下進行, 而不會隨機決定.

現在的前端領域, 隨著JS框架, UI框架和各種庫的豐富, 前端架構也變得十分的重要. 如果一個大型項目沒有合理的前端架構設計, 那么前端代碼可能因為不同的開發人員隨意的引入各種庫和UI框架, 導致代碼量變得異常臃腫, 最終結果可能是代碼變得無法維護, 頁面性能低下,不得已只能推翻重構. 所以我們需要在項目開始前, 同樣的需要對前端代碼進行架構, 一旦前端架構師設計出所有前端開發人員都要遵循的檢驗機制, 建立起系統設計的規范, 那么項目就擁有了可以衡量代碼質量的標準, 前端開發人員也能享受到更高效的工作流. 所以, 前端架構的定義可以用以下一句話來總結:

前端架構是一系列工具和流程的集合, 旨在提升前端代碼的質量, 并實現高效, 可持續的工作流.

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

歸根到底, 所有的網站都是由一堆文本文件和資源文件組成的. 當我們面對制作網站所產生的大量代碼時, 就會發現為代碼和資源設定一個期望是多么重要. 在代碼部分, 我們會專注于如果實現系統架構中的HTML, CSS, JavaScript.

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

要構建一個可擴展和可持續優化的系統, 必須保證新代碼和老代碼能夠很好的兼容. 我們的代碼不會獨立存在, 它們都是大型系統中的一部分. 創建覆蓋面廣泛的測試方案, 能確保老代碼還能正常運作.

一般而言, 如果不是團隊中的重要成員要離開, 我們幾乎都不會意識到文檔的重要性. 等到那個時候, 大家將不得不停下手頭的工作, 優先編寫所有的文檔. 作為前端機構師, 你要善于在項目開發的同時編寫良好的文檔.

軟件測試是在規定的條件下對程序進行操作, 以發現程序中的錯誤, 衡量軟件質量, 并對其是否能滿足設計要求進行評估的過程, 軟件測試的目的是希望以最小的代價盡可能多地找出軟件中潛在的錯誤和缺陷.

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

長久以來, 這種傳統手工測試在各大公司廣泛應用, 并已被證明能夠行知有效的保證產品質量, 但伴隨著互聯網技術的發展, 這種傳統的測試模式已經顯示出越來越多的瓶頸.

1. 重復性工作, 測試質量低

現在的互聯網產品開發研究的是短平快, 小步快走, 短則兩三天, 長則一星期就會發布新版本. 在這短短的時間里, 測試人員需要把新版本部署到測試環境, 更新數據庫 然后對所有的測試用例進行手工校驗. 這個過程事件緊迫, 工作量大, 而且具有很高的機械性和重復性, 當測試人員長期工作在重復性的驗證事物上, 往往會因為思維習慣而忽略新出現的問題, 最后導致不僅測試人員自身缺乏工作熱情, 而且測試質量更難以保證.

2. 測試效率低

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

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

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

4. 無法有效兼顧多瀏覽器, 多平臺

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

1. 單元測試(Unit Test)

在軟件開發過程中, 最基本的測試就是單元測試, 這是針對程序單元(軟件設計的最小單位)來正確性檢驗的測試工作. 程序單元是應用的最小可測試部件. 在過程化編程中, 一個單元就是單個程序, 函數, 過程等; 對于面向對象編程, 最小單元就是方法. 在企業的質量控制體系中, 單元測試是由開發部門在軟件提交測試部門前完成.

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

2. 集成測試(Integration Test)

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

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

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

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

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

需要搭建專門的測試環境模擬真實的用戶場景, 成本較高

測試用例復雜, 運行時間長

一旦測試發現問題, 由于涉及的模塊比較多, 定位問題難度較高

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

1. TDD的優勢

TDD的基本思路就是通過測試來推動整個開發的進行。而測試驅動開發技術并不只是單純的測試工作。

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

通過編寫這部分代碼的測試用例，對其功能的分解、使用過程、接口都進行了設計。而且這種從使用角度對代碼的設計通常更符合后期開發的需求。可測試的要求，對代碼的內聚性的提高和復用都非常有益。因此測試驅動開發也是一種代碼設計的過程。

開發人員通常對編寫文檔非常厭煩，但要使用、理解別人的代碼時通常又希望能有文檔進行指導。而測試驅動開發過程中產生的測試用例代碼就是對代碼的最好的解釋。

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

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

測試驅動開發的基本思想就是在開發功能代碼之前，先編寫測試代碼。也就是說在明確要開發某個功能后，首先思考如何對這個功能進行測試，并完成測試代碼的編寫，然后編寫相關的代碼滿足這些測試用例。然后循環進行添加其他功能，直到完全部功能的開發。

測試驅動開發的基本過程如下：

明確當前要完成的功能。可以記錄成一個 TODO 列表。

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

測試代碼編譯不通過。

編寫對應的功能代碼。

測試通過。

對代碼進行重構，并保證測試通過。

循環完成所有功能的開發。

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

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

Karma是由Google團隊開發的一個測試工具, 它不是一個測試框架, 只是一個跑測試的驅動. 你可以通過karma的配置文件集合你喜歡的框架, 斷言庫和瀏覽器.

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

IBM: 測試驅動開發(TDD)