閱讀688 返回首頁    go 技術社區[雲棲]

React全家桶與前端單元測試藝術

TL;DR——什麼是好的單元測試?

其實我是個標題黨，單元測試根本沒有“藝術”可言。

好的測試來自於好的代碼，如果說有藝術，那也是代碼的藝術。

注：以下“測試”一詞，如非特指均為單元測試。

React全家桶與前端單元測試藝術

單元測試的好壞在於“單元”而不在“測試”。如果一個係統毫無單元可言，那就沒法進行單元測試，幾乎隻能用 Selenium 做大量的E2E測試，其成本和穩定性可想而知。科學的單元劃分可以讓你擺脫mock，減少依賴，提高並行度，不依賴實現/易重構，提高測試對業務的覆蓋率，以及易學易用，大幅減少測試代碼。

最好的單元是返回簡單數據結構的函數：函數是最基本的抽象，可大可小，不需要mock，隻依靠傳參。簡單數據結構可以判等。 最好的測試工具是Assert.Equal這種的：隻是判等。判等容易，判斷發生了什麼很難。你可以看到後麵對於DOM和異步操作這些和副作用相關的例子都靠判等測試。把作用冪等於數據，拿到數據就一定發生作用，然後再測數據，是一個基本思路。

以上是你以前學習測試第一天就會的內容，所以不存在門檻。

為什麼不談TDD?

首先， TDD 肯定是有價值的(價值大小不論)。反對TDD的原因一般比較明顯，對於TDD是否帶來正收益不確定(動機不足)。 某些項目質量要求很高，預算寬綽，TDD勢在必行。某些項目比較緊急，或者並非關鍵或無長期維護計劃，TDD理由就不充分。

為什麼談測試?

因為測試難。

第一難學，第二難寫。寫測試是個挺困難的活，要在測試裏正確重演業務要費好大勁，隻能靠反複練習。雖然這些測試在某些項目中是值得的，但是可能並不適合其他某些項目的基本情況。

測試難，就代表訓練成本高，生產成本也高，收益就下降。要提高采用TDD的動機，與其說服別人，不如從簡化測試開始。

React全家桶與前端單元測試藝術
(圖片來自： https://t.cn/Rpw9WKg )

為什麼談前端測試?

一般項目都是後端測試覆蓋率高，同時後端套路也比較固定。測RESTful API粒度足夠大，可以很好地避開實現並且覆蓋業務。同時RESTful API一般也正好對應Web框架的Action handler，在這裏同時它粒度也足夠小，剛好可以直接調用而不啟動真的Web server，使得測試最大程度並行化。所以這樣測試收益總是最高的，爭議很小。

前端不說套路不固定，測不測都有待商榷。因為前端流派不統一，資源不規則，邊界也不清晰，有渲染又有點業務，有導航有請求，很多團隊不測試/測Model/測Component/測E2E，五花八門。 但得益於JavaScript本身，前端測試其實是可以非常高效的。

下麵你可以看到各種極簡極快的測試工具和測試方式，並且它們完全可以 貫穿開發始終，而非僅給Hello World體量項目準備的 ，你可以在很大的全家桶項目中完全機械地套用這些方法。(機械也是極限的一部分，你不應該在使用工具過程中麵臨太多抉擇，而應當專注於將業務翻譯成測試)。

為什麼談React全家桶?

前端從每周刷新一個框架，穩定到了 Angular , React , Vue 3個主流框架並存的階段。網絡中爭論這三個框架蓋的樓已經可以繞太陽係了。根據蓋的各種大樓看來，現在哪個更優秀還沒個定論。不過具體到單元測試方麵，得益於Virtual DOM本身和模塊化設計(不然全家桶白叫了)，React全家桶明顯更優秀些。

測試工具

我們本篇中的測試有三個目標： 學得快，寫得快，跑得快 。

React全家桶與前端單元測試藝術
(圖片來自： https://t.cn/RpwCke3 )

平台上 Selenium , Phantom , Chrome , 包括 Karma 都比較重，最好的測試框架就是直接跑在 node 上的。本著極限編程的原則，我們將測試本身和測試環境盡可能簡化，以達到加快測試速度，最終反饋到開發速度的目的。

我們使用 AVA 進行測試，它非常簡潔，速度非常快，和 mocha 不同，它默認會啟動多線程並發測試。因此我們的測試必須減少共享狀態來提高並發能力，不然就會出現意想不到的錯誤。安裝和運行：



    

  1. yarn add ava 
    2. 

  2. ava --watch 
    3. 



這樣可以運行並watch測試。改變代碼測試結果會立刻改變，你也可以看到友善的錯誤信息，以及expected和actual之間的diff。寫下第一段測試：




    

  1. import test from 'ava' 
    2. 

  2.  
    3. 

  3. test(t => { 
    4. 

  4.   t.is(1 + 1, 2) 
    5. 

  5. }) 
    6. 



除了is方法以外，我們還會用到deepEqual和true方法。好，你現在已經完全會用AVA了。其他的功能我們完全不關心。


Redux測試 (Model測試)


Redux 就是用一堆Reducer函數來reduce所有事件用來做全局Store的狀態機( FSM )。用源碼本身介紹它甚至比用上一小段文字介紹還快：




    

  1. const createStore = reducer => { 
    2. 

  2.   let state, listeners = [] 
    3. 

  3.  
    4. 

  4.   const dispatch = action => { 
    5. 

  5.     state = reducer(state, action) 
    6. 

  6.     listeners.forEach(listeners => listeners()) 
    7. 

  7.   } 
    8. 

  8.  
    9. 

  9.   return { 
    10. 

  10.     getState() { return state }, 
    11. 

  11.     subscribe(listener) { 
    12. 

  12.       listeners.push(listener) 
    13. 

  13.       return () => { listeners = listeners.filter(l => l !== listener)} 
    14. 

  14.     }, 
    15. 

  15.     dispatch, 
    16. 

  16.   } 
    17. 

  17. } 
    18. 



這是一個簡化版的代碼，去掉了拋錯等等細節，但功能是完整的。把你自己寫的reducer扔進去，然後可以發事件來使其更新，你還可以訂閱它來拿狀態。有點像
Event Sourcing ，以消息而非調用來處理邏輯，更新和訂閱的邏輯不在一起(事件是寫模型，各種view就是多個讀模型)。


reducer幾乎包括了我們所有前端業務的核心，測好它就測了大半。它們全都是 (State, Action) =>
nextState 形式的純函數，無異步操作，用swtich case來模擬模式匹配來處理事件。比如用喜聞樂見的簡陋版的棧停車場舉例：




    

  1. export const parkingLot = (state = [], action) => { 
    2. 

  2.   switch (action.type) { 
    3. 

  3.     case 'parkingLot/PARK': 
    4. 

  4.       return [action.car, ...state] 
    5. 

  5.     case 'parkingLot/PICK': 
    6. 

  6.       const [_, ...rest] = state 
    7. 

  7.       return rest 
    8. 

  8.     default: return state 
    9. 

  9.   } 
    10. 

  10. } 
    11. 



Reducer是這麼用的：




    

  1. const store = createStore(parkingLot) 
    2. 

  2. store.subscribe(() => renderMyView(store.getState())) 
    3. 

  3. store.dispatch({ type: 'parkingLot/PARK' }) 
    4. 



好，現在你又理解了Redux。那我們可以看看怎麼測試上麵的parkingLot reducer了：




    

  1. test('parking lot', t => { 
    2. 

  2.   const initial = parkingLot(undefined, {}) 
    3. 

  3.   t.deepEqual(initial, [], 'should be empty when init') 
    4. 

  4.  
    5. 

  5.   const parked = parkingLot(initial, { type: 'parkingLot/PARK', car: 'Tesla Model S' }) 
    6. 

  6.   t.deepEqual(parked, ['Tesla Model S'], 'should park Model S in lot') 
    7. 

  7.  
    8. 

  8.   const picked = parkingLot(parked, { type: 'parkingLot/PICK' }) 
    9. 

  9.   t.deepEqual(picked, [], 'should remove the car') 
    10. 

  10. }) 
    11. 



它就是你第一天學測試就會寫的那種測試。這些測試不受任何上下文影響，是冪等的。試著把那幾個const聲明的state挪到任何地方，你都可以發現測試還是正確的，這和我們平常小心翼翼分離各個測試case，並用beforeEach和afterEach重置截然不同。


React全家桶與前端單元測試藝術

(圖片來自： https://t.cn/RpwS3AK )


測試Reducer是非常機械的，你不需要問自己“我到底應該測哪些東西”，隻需要機械地測試初始state和每個switch
case就好了。(小秘密：redux-devtools寫完實現，在瀏覽器裏打開，反過來還可以自動生成各種框架的測試代碼，粘貼回來就行了。推薦不寫測試的項目嚐試下，反正白送的測試……而且跟你寫的沒兩樣)


隨著業務變得複雜，當state樹變大時，我們可以將reducer結構繼續往下抽，並繼續傳遞事件，函數沒有this，重構起來比普通OO要簡單得多，就不贅述了。這時候測試還是完全一樣的，這種樹形結構保證了我們能最大限度地覆蓋一個bounded
context—也就是root reducer。


另外更好的方式是用t.is(斷言引用相同)而非t.deepEqual。但是JavaScript對象本身是可變的，引入 immutable.js 可以讓你隻用t.is測試，不過immutable的API有點別扭，不展開了。


組件測試 (View測試)


React是一個View library，它幹的活就是DOM
domain裏的兩個事：渲染和捕獲事件。我們在這裏依然從簡，隻用stateless
component這個子集，雖然在用到生命周期方法的時候需要用一下class，但絕大多數時候應該隻用stateless component。


它以Virtual
DOM的形式封裝了惡心的瀏覽器基礎設施，讓我們以函數和數據結構來描述組件，所以和大部分框架不同，我們的測試依然可以在node上並行運行。如果用Karma
+ Chrome真正地渲染測試，你會發現共享一個瀏覽器實例的測試非常慢，幾乎無法watch測試，因此我們的TDD
cycle就會變得不那麼流暢了。


最基本的就是 state => UI 這種純函數組件：




  1. const Greeter = ({ name }) => <p>Greetings {name}!</p> 


使用的時候就像HTML一樣傳遞attribute就可以了。




  1. render(<Greeter name="React"/>, document.body) 


最簡單的測試還是判等，我們用一個叫 jsx-test-helpers 的庫來幫我們渲染：




    

  1. import { renderJSX, JSX } from 'jsx-test-helpers' 
    2. 

  2.  
    3. 

  3. const Paragraph = ({ children }) => <p>{children}</p> 
    4. 

  4. const Greeter = ({ name }) => <Paragraph>Greetings {name}!</Paragraph> 
    5. 

  5.  
    6. 

  6. test('Greeter', t => { 
    7. 

  7.   t.is(renderJSX(<Greeter name="React"/>),  
    8. 

  8.        JSX(<Paragraph>Greetings React!</Paragraph>),  
    9. 

  9.        'should render greeting text with name') 
    10. 

  10. }) 
    11. 



這裏我多加了一層叫做Paragraph的組件，它的作用僅僅是傳遞給p標簽，children這個prop表示XML標簽傳進來的子元素。多加這層Paragraph是為了展示renderJSX隻向下渲染了一層，而非最終需要渲染的p標簽。這樣我們在View上的測試粒度就會變得更小，成本更低，速度更快。


React全家桶與前端單元測試藝術

(圖片來自： https://t.cn/RpwYskG )


View不像業務本身那麼穩定，細粒度低成本的快速測試更劃算些，這也是為什麼我們的View都隻是接受參數渲染，這樣你隻用測很少的case就能保證View可以正確渲染。假如你的FSM
Model有M種可能性，View顯示的邏輯有N種，如果將兩個集成在一起測試可能就需要M×N種Path，如果分開測就有M+N種。View和Model的邊界清晰時，你的Model測試不容易被更困難的View測試幹擾，View測試也減少了混沌程度，需要測試的情形就減少了。


我們的組件不應該隻有渲染，還有事件，比如我們封裝個TextField組件：




    

  1. const TextField = ({ label, onChange }) => <label> 
    2. 

  2.   {label} 
    3. 

  3.   <input type="text" onChange={onChange} /> 
    4. 

  4. </label> 
    5. 



當然我們還可以判等，隻要onChange函數引用相同就好了。




    

  1. test('TextField', t => { 
    2. 

  2.   const onChange = () => {} 
    3. 

  3.   const actual = renderJSX(<TextField label="Email" onChange={onChange} />) 
    4. 

  4.   const expected = JSX(<label> 
    5. 

  5.     Email 
    6. 

  6.     <input type="text" onChange={onChange}/> 
    7. 

  7.   </label>) 
    8. 

  8.   t.is(actual, expected) 
    9. 

  9. }) 
    10. 



當然有時候你的組件更複雜些，測試時並不關心組件是不是完全按你想要的樣子渲染，可能你想像 jQuery 一樣選擇什麼，觸發什麼。這樣可以用更主流的 enzyme 來測試：




    

  1. import {shallow} from 'enzyme' 
    2. 

  2. import sinon from 'sinon' 
    3. 

  3.  
    4. 

  4. test('TextField with enzyme', t => { 
    5. 

  5.   const onChange = sinon.spy() 
    6. 

  6.   const wrapper = shallow(<TextField label="Email" onChange={onChange} />) 
    7. 

  7.   t.true(wrapper.contains(<label>Email</label>), 'should render label') 
    8. 

  8.  
    9. 

  9.   const event = { target: { value: 'foo@bar.com' } } 
    10. 

  10.   wrapper.find('input').simulate('change', event) 
    11. 

  11.   t.true(onChange.calledWith(event)) 
    12. 

  12. }) 
    13. 



這裏用的shallow顧名思義，也是向下渲染一層。此外我們還用了spy，這樣測試就變得有點複雜了，丟掉了我們之前聲明式的優雅，所以組件還是小一點、一下測完比較好。


還不夠快?Facebook就覺得不夠快，他們覺得View測試成本比較浪費，幹脆搞了個Snapshot測試——意思就是照個像，隻斷言它不變。下次誰改了別的地方不小心影響到這裏，就會掛掉，如果無意的就修好，如果有意的話和git一樣commit一下就修好了：




    

  1. import render from 'react-test-renderer' 
    2. 

  2.  
    3. 

  3. test('Greeter', t => { 
    4. 

  4.   const tree = render.create(<Greeter name="React"/>).toJSON() 
    5. 

  5.   t.snapshot(tree, 'should not change') 
    6. 

  6. }) 
    7. 



當你修改Greeter的時候，測試就會掛掉，這時候運行：




  1. ava --update-snapshots 


就好了。Facebook自家的 Jest 對snapshot的支持更好，當snapshot不匹配時按個y/n就完事了，夠快了吧。要有更快的可能就是不測了……


小結


這節裏我們展示了3種測試View的不同方式，它們都比傳統框架更簡單更快速。我們的思路還是以判等為主，但不同於Model，粒度越大越好。View測試粒度越小越好，足夠小、足夠冪等之後，其實不用測試你也可以發現組件總是按照預期工作。相比之下MVVM天然有一種讓View和Model粒度擬合的傾向，很容易讓測試變得既難測又缺乏價值。


React全家桶與前端單元測試藝術


異步Effect測試


這算個續集……異步操作不複雜的項目可以無視這段，可以選擇性不測。


React先解決了惡心的DOM問題，把Model的問題留下了。然後Redux把同步邏輯解決了，其實前端還留下異步操作的大問題沒有解決。這種類似“Unix隻做一件事”的哲學是React全家桶的根基。我們用一個叫做
Redux-saga 的庫來展現全家桶的異步測試怎麼寫，Redux模仿的目標是 Elm
architecture，但是簡化掉了Elm的作用模型，隻保留了同步模型，Redux-saga其實就是把Elm的作用模型又拿回來了。


Saga是一種worker模式，很早之前在Java社區就存在了。Redux-saga抽象出來多種通用的作用比如call / takeEvery等等，然後有了這些作用，我們又可以愉快地判等了。比如：




    

  1. import { takeEvery, put, call, fork, cancel } from 'redux-saga/effects' 
    2. 

  2.  
    3. 

  3. 
function *account() { 
    4. 

  4.   yield call(takeEvery, 'login/REQUESTED', login) 
    5. 

  5. } 
    6. 

  6. 
function *login({ name, password }) { 
    7. 

  7.   try { 
    8. 

  8.     const { token } = yield call(fetch, '/login', { method: 'POST', body: { name, password } }) 
    9. 

  9.     yield put({ type: 'login/SUCCEEDED', token }) 
    10. 

  10.   } 
    11. 

  11.   catch (error) { 
    12. 

  12.     yield put ({ type: 'login/FAILED', error }) 
    13. 

  13.   } 
    14. 

  14. } 
    15. 



這段代碼乍看起來很醜，這是因為它把程序裏所有異步操作全都集中在自己身上了。其他部分都可以開心地發同步事件了，此外有了Saga之後Redux終於有了“用事件觸發事件”的機製了，隻用redux，應用複雜到一定程度你一定會想這個問題的。


這是個最普通的API處理saga，一個account worker看到每個’login/REQUESTED’就會forward給login
worker(takeEvery)，讓它繼續管下麵的事。然後login
worker拿到消息就會去發請求(call)，之後傻傻地等著回複，或者是出錯。最後它會發出和結果相關的事件。用這個方式你可以輕鬆解決瘋狂難度的異步問題。




    

  1. test('account saga', t => { 
    2. 

  2.   const gen = account() 
    3. 

  3.   t.deepEqual(gen.next().value, call(takeEvery, 'login/REQUESTED', login)) 
    4. 

  4. }) 
    5. 

  5.  
    6. 

  6. test('login saga', t => { 
    7. 

  7.   const gen = login({ name: 'John', password: 'super-secret-123'}) 
    8. 

  8.  
    9. 

  9.   const request = gen.next().value 
    10. 

  10.   t.deepEqual(request, call(fetch, '/login', { method: 'POST', body: { name: 'John', password: 'super-secret-123'} })) 
    11. 

  11.   const response = gen.next({ token: 'non-human-readable-token' }).value 
    12. 

  12.   t.deepEqual(response, put({ type: 'login/SUCCEEDED', token: 'non-human-readable-token' })) 
    13. 

  13.   const failure = gen.throw('You code just exploded!').value 
    14. 

  14.   t.deepEqual(failure, put({ type: 'login/FAILED', error: 'You code just exploded!'})) 
    15. 

  15. }) 
    16. 



你看我們的測試連異步操作都還可以無恥地判等。call就是以某些參數調用某個函數，put就是發事件。


可以試著把fetch覆蓋成空函數，你可以發現實際上副作用根本沒發生，“fetch到底是個啥”對測試一點影響都沒有。你可能發現了，其實saga就是用數據結構表示作用，而不著急執行，在這裏又走回冪等的老路了。這和React
Virtual DOM的思路異曲同工。


結語


首先是文章開頭提到的TL;DR的內容。函數是個好東西，測函數不等同“測1+1=2”這種沒營養的單元，函數是可以包含很大上下文的。這種輸入輸出的模型既簡單又有效。


我們消滅了mock，減少了依賴，並發了測試，加快了速度，降低了門檻，減少了測試路徑等等。如果你的React項目原來在TDD的邊緣搖擺不定，現在是時候入一發這種唯快不破了。


全家桶讓Model/View/Async這三者之間的邊界變得清晰，任由業務變更，它們之間的職責是不會互相替代的，這樣你測它們的時候才更容易。後端之所以測試穩定是因為有API。所以想讓前端好測也是一樣的思路。


文中好多次提到“冪等”這個概念，冪等可以讓你減少測試的case，寫代碼更有底氣。拋開測試不談，代碼冪等的地方越多，程序越可控可預期。其實仔細思考一下我們的實際項目，大部分業務都是非常確定的，並沒有什麼隨機因素。為什麼最後還是會出現很多隨機現象呢?


聲明優於命令，描述發生什麼、想要什麼比親自指導具體步驟好。


消息機製優於調用機製。Smalltalk > Simula。其實RESTful
API一定程度上也是消息。簡單的對象直接互相作用是完全沒問題的，人作為複雜對象主要通過語言媒介來交流，聽到內容思考其中的含義，而不是靠肢體接觸，或者像連體嬰兒那樣共享器官。所以才有一句俗語叫“你的對象都想成長為Actor”。


從View的幾種測試裏我們也可以看到，測試並不是隻有測或者不測這兩種選擇，我們老提測試金字塔，意思是測試可多可少，不同層級的測試保持正金字塔形狀比較健康，像今天我們說的就可以大幅加寬你測試金字塔的底座。所以你的項目有可能測試過少，也可能測試過度，所以時間可以動態調整。


沒用全家桶的項目可以把“大Model小View”的思想拿走，這樣更容易於專注價值。盡量抽出Model層，不要把邏輯寫在VM裏，看那樣似省事，行數在測試裏都還回來了。





作者：佚名


來源：51CTO


最後更新：2017-09-12 15:03:01
  上一篇：go  Java 9的JDK中值得期待的：不僅是模塊化 
  下一篇：go  Python Web框架：Django vs Flask vs Pyramid