Vue 應用單元測試的策略與實踐 01 - 前言和目標

時間 2019-11-16

標籤 vue 應用單元測試策略實踐前言目標简体版

原文原文鏈接

本文首發於 Vue 應用單元測試的策略與實踐 01 - 前言和目標 | 呂立青的博客javascript

歡迎關注知乎專欄 —— 前端的逆襲（凡可 JavaScript，終將 JavaScript。）html

歡迎關注個人博客，知乎，GitHub，掘金。前端

前言

本文主要嘗試解決三個問題：vue

在 TDD 作完Tasking列完實例化數據以後，徹底沒有UT基礎不知道該怎麼寫單元測試？
在Vue應用的單元測試中，對UI組件和vuex store等測試的區別有何不一樣？顆粒度該細到什麼程度？
測試收益如何最大化，如何配置高性價比的測試策略，即什麼地方到底該花力氣測試，什麼地方又能夠暫且放一放？

不談論的包括：java

ATT 驗收測試或 E2E 端到端測試，這個是我想進一步探索的話題，特別是在TDD的語境下。#322
爲何要 TDD？可是我會講爲何要 UT 單元測試。測試和TDD是兩碼事，而光是自動化測試的好處就已經足夠多，可是如何作到更好的自動化和持續集成，那就須要TDD來指引方向。
Snapshot Testing 快照測試，其實我是很承認快照這種形式，但須要改進其工做流，至少結合Image Snapshot和Storybook等工具，甚至更應該放到CI上去。#311

下面我就來結合具體場景，進一步實例化這些問題，舉幾個🌰：git

在 TDD 作完Tasking列完實例化數據以後，徹底沒有UT基礎不知道該怎麼寫單元測試？

// Given
一個徹底沒有UT基礎的新人🚶
// When
當他🚶閱讀和練習本文的Jest的部分
// Then
他可以把Given/When/Then的套路學會
他可以學會Jest的基本用法，包括測試suite和斷言等語法
他可以學會Jest中測試異步的幾種方式
複製代碼

在Vue應用的單元測試中，對UI組件和vuex store等測試的區別有何不一樣？顆粒度該細到什麼程度？

// Given
一個有基本的UT知識但沒寫過Vue測試的新人🚶
// When
當他🚶閱讀和練習本文的Vue單元測試的部分
// Then
固然，他可以學會Vue組件在測試當中的幾種渲染方式
他可以學會UI組件的分類，特別是交互行爲的測試方式
他可以對Vuex概念的理解更加深刻，且知道 `Redux-like` 架構的好處
他可以合理測試vuex store的mutation和getter中的業務邏輯
他可以測試組件如何正確dispatch action以及action中如何作異步操做
複製代碼

Vue項目中測試收益如何最大化，如何配置高性價比的測試策略，即什麼地方到底該花力氣測試，什麼地方又能夠暫且放一放？

// Given
一個具有UT基礎但找不到着力點的求索之徒🐒
// When
當他🚶閱讀本文的Vue應用測試策略部分
// Then
他可以找到測試的重點，從新燃起對UT的熱情🔥
他可以在項目背景下合理配置單元測試的測試策略
複製代碼

因而乎，這就是本系列文章的大綱，先放出來給你們一個對於Vue應用單元測試的全局觀：程序員

## 單元測試基礎

### 爲何選擇 Jest
### Jest 的基本用法
### 該如何測試異步代碼？
### 單元測試與自動化的意義

## Vue 單元測試

### Vue 組件的渲染方式
### Wrapper `find()` 方法與選擇器
### UI 組件交互行爲的測試

## Vuex 單元測試

### CQRS 與 `Redux-like` 架構
### 如何對 Vuex 進行單元測試
### Vue組件和Vuex store的交互

## Vue應用測試策略

### 單元測試的特色及其位置
### 單元測試的關注點
### 應用測試的測試策略
複製代碼

😯 哦豁，正文終於開始……github

爲何要有單元測試？

引用好友鮮明的觀點就是：寫很差是能力問題，不寫則是態度問題。單元測試客觀上可讓開發者的工做更高效，Vue 應用的單元測試是必定要的。vuex

單元測試的上下文

談任何東西都必定要有個上下文。你的論述不能是「由於單元測試有這些好處，因此咱們要作單元測試」，而應該是「不作單元測試咱們會遇到什麼問題」，這樣才能回答「爲何要寫單元測試」的問題。那麼咱們談論單元測試的上下文是什麼呢？不作單元測試咱們會遇到什麼問題呢？架構

上圖爲一個產品從 idea 分析、設計、開發、測試到交付並獲取市場反饋的過程。

而單元測試的上下文就是存在於「敏捷」當中。敏捷爲的是更快地交付有價值的可工做的軟件。爲此，它有一個指標來度量這個「更快」，那就是 lead time，它度量的是一個 idea 從提出被驗證，到最終上生產環境面對用戶的時間。顯然，這個時間越短，軟件得到反饋的時間就越短，對價值的驗證就越快發生。

單元測試的意義

這個結論對咱們寫不寫單元測試有什麼影響呢？答案是，不寫單元測試，你就快不起來。爲啥呢？由於每次發佈，你都要投入人力來進行手工測試；由於沒有測試，你傾向於不敢隨意重構，這又致使代碼逐漸腐化，複雜度使得你的開發速度下降。

那麼在這個上下文中來談要不要單元測試，咱們就能夠頗有根據了，而不是「開發爽了就用，不爽就不用」這樣含糊的答案：

若是你說個人業務部門不須要頻繁上線，而且我有足夠的人力來覆蓋手工測試，那你能夠不用單元測試
若是你說我不在乎代碼腐化，而且我也不作重構，那你能夠不用單元測試
若是你說我不在乎代碼質量，好幾個沒有測試保護的 if-else 裸奔也不在話下，腦很差還作什麼程序員，那你能夠不用單元測試
若是你說我確有快速部署的需求，但咱們不 care 質量問題，出迴歸問題就修，那你能夠不用單元測試

除此以外，你就須要寫單元測試。若是你想隨時整理重構代碼，那麼你須要寫單元測試；若是你想有自動化的測試套件來幫你快速驗證提交的完整性，那麼你須要寫單元測試。

單元測試與自動化的關係

綜上，咱們用來談論單元測試的「透鏡」是什麼呢？一言以蔽之，兩點：反饋速度和自動化。

自動化回答的是要不要自動化的單元測試這個問題。測試是重構的惟一保障，也就是說，沒有測試，基本上就無法重構代碼（重構指的是不改變軟件可觀測行爲的前提下改善代碼內部設計或實現），基本上就只能看着代碼腐化。那麼，基本上只要你的系統須要持續發展，你就須要單元測試。

反饋速度回答的是要不要 TDD、測試先行仍是後補這個問題。答案是，須要 TDD，最好先行，由於能夠提升反饋速度，縮短反饋週期，與此同時減小沒必要要的浪費。

至此，回答了「爲何咱們須要寫單元測試」的問題。下面讓咱們來談談如何寫好 JavaScript 代碼和 Vue 應用框架的單元測試。

如何選擇一個測試框架？

衆所周知，JavaScript 世界裏最不缺的就是輪子，測試框架也是如此。其實這裏的子標題就是爲何選擇 Jest？有時候安於現狀，只不過是由於咱們沒有見過理想的模樣。只有當咱們見過更好的世界和更好的測試框架，纔會驚呼「原來世界是這樣美好呀！我怎麼都沒有想到呢？」

引自技術雷達：Jest是一個「零配置」的前端測試工具，具備諸如模擬和代碼覆蓋之類的開箱即用特性，主要用於React和其餘JavaScript框架。

咱們團隊對採用JEST作前端測試的結果很是滿意。它提供了一種「零配置」的開發體驗，並具有諸多開箱即用的功能，好比 Mock 和代碼覆蓋率等。你不只能夠將此測試框架應用於React.js應用程序，也能夠應用於其餘 JavaScript 框架。Jest 常常被炒做的功能之一是用戶界面的快照測試。快照測試能夠做爲測試金字塔上層一個很好的補充，但請記住，單元測試仍然是堅實的基礎。

一個好的測試框架，Jest 的幾大好處能夠涵蓋爲：

Fast 天下武功，惟快不破。確實很快，雖然實測下來跟 Mocha 新版本仍是慢了些，之後找個機會再測一次。
Opinionated 不須要你作出選擇和配置，就能提供全部的東西，好比Mock（幹掉Sinon）、Test Runner（幹掉Karma）、Matcher（幹掉Chai）、Test Coverage（內置istanbul）
Watch Mode 守護模式。很是注重開發者體驗，可以在編碼的時候幫助咱們快速得到測試結果的反饋。
Snapshot Testing 快照測試。這是值得爭議的一點，前文也提到過會專門開個issue來討論，在此再也不贅述。

最後，總結一下 Jest

Jest 做爲一個測試框架，其最大的特色就在於它是一個很是有效的解決方案，不須要與其餘測試庫交互來執行它的工做。與此同時 Jest 很是注重開發者體驗，這一點也是特別值得欣賞，如今市面上關注開發者（「人」）體驗的開發框架和工具實在很少，而Jest Watch模式的核心就在於快速得到反饋，雖然我沒在命令行使用而是WebStorm但亦能夠與之結合。

ps: 除此以外，還有不少開發者體驗亦值得細細品味與發現，特別是Jest自己來自Facebook的工程化支持也是特別棒的，這個講述如何開發Jest的官方視頻值得一看：Building High-Quality JavaScript Tools。