測試是個永恆的主題,咱們一塊兒探尋一下前端單元測試的前因後果。html
單元測試在維基百科上的定義爲前端
單元測試(英語:Unit Testing)又稱爲模塊測試,是針對程序模塊(軟件設計的最小單位)來進行正確性檢驗的測試工做。vue
在前端中,模塊能夠指功能模塊和組件模塊,也就是一個函數,一個類或者是一個組件。ios
項目的發展愈來愈大,模塊與模塊之間的聯繫和邏輯愈來愈複雜,錯誤信息定位也愈來愈難排查,在這樣的項目下開發新功能和重構,付出的時間成本,管理成本大。git
這就是單元測試存在的意義:github
不是任何項目都要寫單元測試,畢竟寫測試用例會增長開發的工做量。寫單元測試的項目須要知足一下幾個條件(但不限於):數據庫
極限編程、測試驅動開發和單元測試以及JUnit的創造者Kent Beck在StackOverflow上,對於單元測試應該寫到什麼程度的問題做出的回答是:編程
老闆爲個人代碼付報酬,而不是測試,因此,我對此的價值觀是——測試越少越好,少到你對你的代碼質量達到了某種自信(我以爲這種的自信標準應該要高於業內的標準, 固然,這種自信也多是種自大)。若是個人編碼生涯中不會犯這種典型的錯誤(如:在構造函數中設了個錯誤的值),那我就不會測試它。我傾向於去對那些有意義的錯誤 作測試,因此,我對一些比較複雜的條件邏輯會異常地當心。當在一個團隊中,我會很是當心的測試那些會讓團隊容易出錯的代碼。瀏覽器
鑑於前輩的觀點,得出測試用例並非寫越全就越好,而應該將測試用例重點覆蓋在關鍵代碼上,儘可能讓測試有意義。這樣的代碼類型有:網絡
類型 | 介紹 | 好處 | 壞處 |
---|---|---|---|
開發前寫好測試用例 | 屬於TTD模式,測試驅動開發 | TTD是被證實能有效提升代碼質量的測試手段 | 不適用需求多變的前端模塊,測試用例也要跟着變 |
開發中寫測試用例 | 先寫好一部分功能代碼,緊跟着寫測試用例 | 測試隨着業務代碼同步 | 相對於開發前要好一點 |
開發後寫測試用例 | 當完成功能後再補上測試用例 | 這時有些業務和模塊已經穩定下來 | 假如單元的邏輯比較複雜,測試的點會多,爲了較快的寫好用例,用例的粒度會變「粗」 |
對比事後,通常比較推薦在開發需求中,功能代碼與測試用例同步進行。
首先要注意,單元測試難的不在於如何寫,而在於代碼設計,模塊與模塊之間要相互獨立,將代碼劃分爲單元可測的代碼,單元可測的代碼不該該依賴其餘模塊,不涉及IO操做,這裏的IO操做不只是指讀寫文件,操做數據庫,還包括AJAX請求,本地存儲,DOM操做等與瀏覽器API相關的操做。合理劃分模塊,模塊間解耦,儘可能不要相互引用,這也是書寫代碼的良好習慣,因此好的單元測試有利於促進系統模塊的合理劃分。
至於使用什麼測試框架和如何使用的問題,網上有不少資料都有介紹。
對比了前端一些熱門的庫的測試用例,既有UI庫也有功能庫,它們的測試用例的類型以下表所示。
項目 | 測試框架 | 單元 | 測試用例 |
---|---|---|---|
Element | Karma | 組件 | 構建是否成功、屬性的UI表現是否一致、觸發的事件運行是否預期 |
Ant-design-vue | jest | 組件 | 屬性的UI表現是否一致、交互事件觸發是否預期、邊界狀況是否被處理 |
Axios | Mocha、Karma | 類和函數模塊 | 模塊的功能點是否正常 |
Vue應用項目 | Vue Test Utils(官方推薦) | 組件、Util函數模塊、Store模塊、API模塊 | 渲染dom後檢驗頁面顯示的數據、檢驗調用API(不訪問網絡,須要mock數據)、Vuex的store、commit或dispatch的檢查和檢測用戶交互等 |
UI庫以組件爲單元,功能庫以類或函數模塊爲單元。而在業務項目中,劃分的模塊每每包括組件、Util函數模塊、Store模塊、API模塊等等。單元測試不可能把這麼多模塊的功能點都一一覆蓋,像上面所說的咱們須要挑揀出重要的、複雜的和易出錯進行單元用例覆蓋,至於那些多變的不重要的功能點能夠先不用針對寫測試用例。
以上內容包括了對單元測試概念性和適用性的講解,只但願能起到前端單元測試指引性的做用,大概意識到才能樣的項目須要引入單元測試,單元測試用例須要覆蓋的點,以及知道如何上手應用框架,至於具體怎樣引入到項目裏面,網上教程比我寫的都要好,並且我也還沒在真正在項目中引入(哈哈,紙上談兵扯理論)。。。
參考文檔: